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EXECUTIVE  SUMMARY 


The  purpose  of  this  report  is  to  identify  mid-term, 
1984-1988,  Automatic  Digital  Network  (AUTODIN)  architecture 
alternatives  and  recommendations  to  meet  user  needs  for 
common- user  record  and  data  communications.  It  provides  the 
framework  for  the  evolutionary  development  of  an  Integrated 
AUTODIN  System  (IAS)  on  a  terminal- to- terminal  basis  to 
include  architectural  design  considerations  for  the  1979  to 
1990  time  frame. 

The  purpose  of  the  Integrated  AUTODIN  System  Architecture 
(IASA)  is  to  guide  the  evolution  of  telecommunications 
systems  toward  a  more  efficient  means  of  message  processing 
and  data  communications  while  offering  standard  solutions  to 
user  reauirements . 

On  5  February  1975,  OSD/DTACCS  (now  ASD/C3I)  tasked  the 
Defense  Communications  Agency  (DCA)  in  coordination  with  the 
Services /Agencies ,  tp  develop  an  IASA  on  a  terminal- to- 
terminal  basis  and  based  on  the  architecture  to  define  a 
common  family  of  AUTODIN  terminal  hardware  and  software.  On 
12  December  1975,  OSD/DTACCS  approved  the  DCA  IASA  develop¬ 
ment  plan.  As  a  result  of  this  plan,  DCA  is  responsible  for 
accomplishing  three  objectives:  (1)  develop  a  system  archi¬ 
tecture  on  a  terminal- to- terminal  basis;  (2)  develop  terminal 
specifications;  and  (3)  develop  related  standards,  formats, 
and  procedures. 

The  overall  objective  of  the  IASA  project  is  to  design 
and  engineer  a  DoD-wide  common-user  system  for  communicating 
narrative  and  data  traffic,  for  the  period  1979  to  1990, 
based  upon  AUTODIN  I  and  AUTODIN  II ,  which  is  complete  and 
integrated  from  end  to  end.  The  1979-1983  implementation 
alternatives  include  determining  the  function,  number  and 
location  of  AUTODIN  I  Switching  Centers  (ASCs) ,  AUTODIN  II 
Packet  Switching  Nodes  (PSNs) ,  Automated  Message  Processing 
Exchanges  (AMPEs),  and  user  terminals.  The  1984  to  1988 
time  frame  will  see  the  implementation  of  new  hardware/ 
software  elements  to  replace  obsolete  equipments.  The 
planning  of  a  smooth  transition  over  the  1979-1990  time 
frame  is  one  of  the  important  aspects  of  the  IAS  architec¬ 
tural  strategy  and  is  developed  throughout  this  report.  In 
addition  to  major  network  elements,  this  report  covers  such 
topics  as  user  requirements,  data  communications  trends, 
standards,  security,  allocation  of  functions,  and  the  IAS 
transition  strategy. 

This  report  identifies  three  alternative  architectures 
for  the  mid-term  (1984-1988)  IAS,  and  describes  the  process 
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and  rationale  for  selecting  the  preferred  (Alternative  II) 
architecture.  The  preferred  architecture  for  the  mid-term 
represents  a  distributed  architecture  where  services  are 
provided  from  a  common  access  area  element.  The  major 
elements  of  the  architecture  are  the  AUTODIN  II  PSNs,  the 
Inter- Service/ Agency  (I-S/A)  AMPEs  and  subscriber  terminals. 
This  report  identifies  the  roles  and  relationships  of  these 
mid-term  IAS  elements,  identifies  the  I-S/A  AMPE  as  the 
replacement  for  today's  AUTODIN  I  switching  centers  and  the 
current  Service /Agency  AMPEs,  and  recommends  an  architectural 
structure  which  moves  switching  functions  closer  to  the  user 
by  use  of  the  enhanced  I-S/A  AMPE.  This  approach,  in  con¬ 
sonance  with  recent  planning  efforts  for  DCS  architectures, 
will  reduce  the  dependency  on  the  more  vulnerable  backbone 
switches  and  should  enhance  overall  survivability. 

Based  upon  the  evaluation  criteria  of  operational  effec¬ 
tiveness,  flexibility,  survivability/availability/support- 
ability,  transition,  and  cost,  the  preferred  mid-term  architec¬ 
ture:  (1)  satisfies  all  of  the  identified  services / functions ; 

(2)  offers  significant  cost  reduction  through  standardization 
of  hardware,  software,  and  operating  procedures;  (3)  provides 
improved  access  reliability;  (4)  permits  improved  speed  of 
service;  (5)  provides  flexibility  in  satisfying  user  unique 
requirements;  (6)  can  be  implemented  in  an  evolutionary 
process  from  the  near-term  1983  architecture;  and  (7)  provides 
the  framework  for  continued  evolutionary  development  of  the 
IAS  through  1988  and  beyond. 

In  contrast  with  the  near-term  IAS,  which  is  constrained 
by  the  use  of  existing  technology  and  equipment,  the  mid¬ 
term  system  begins  to  exploit  the  advantages  of  the  state- 
of-the-art  in  communications.  Accordingly,  the  mid-term 
transition  strategy  is  driven  by  the  following  architectual 
objectives :  (1)  preserve  continuity  of  existing  network 
services;  (2)  provide  for  needed  new  services;  (3)  enhance 
system  survivability;  (4)  enhance  tactical  and  allied  forces 
interoperability;  and  (5)  replace  obsolete  equipment  with 
new  or  augmented  standard  network  elements  (e.g.  replace 
AMPEs  with  I-S/A  AMPEs). 

The  December  1977  IASA  Report  (Part  1)  provided  AUTODIN 
implementation  alternatives  and  recommendations  through 
1983.  This  report  (Part  2)  provides  AUTODIN  architectural 
alternatives  and  recommendations  for  the  period  1984  through 
1988.  Section  V  provides  conclusions  and  recommendations  to 
this  IASA  Project  report.  In  October  1979,  an  IASA  (Part  3) 
report  will  be  provided  to  include  standards  and  functional 
specifications  for  a  common  family  of  terminals. 
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SECTION  I 


INTRODUCTION 


A.  Purpose.  This  report  identifies  mid-term,  1984-1988, 
Automatic  Digital  Network  (AUTODIN)  architecture  alterna¬ 
tives  and  recommendations  to  meet  user  needs  for  common-user 
record  and  data  communications. 

The  purpose  of  the  Integrated  AUTODIN  System  Architecture 
(IASA)  is  not  to  create  a  new  system  to  be  superimposed  on 
all  other  user  systems  in  a  duplicate  way,  nor  is  it  to 
exploit  technological  advances  in  the  data  processing  industry 
when  there  is  no  well  defined  need  to  do  so.  The  purpose  of 
the  IASA  is  to  guide  the  evolution  of  telecommunications 
systems  towards  a  more  secure,  accurate,  survivable,  and 
efficient  means  of  message  processing  and  data  communications 
while  offering  standard  solutions  to  user  requirements. 

This  report  identifies  three  alternative  architectures 
for  the  mid-term  (1984-1988)  Integrated  AUTODIN  System 
(IAS),  and  describes  the  process  and  rationale  for  selecting 
the  preferred  architecture.  In  addition,  this  report  identi¬ 
fies  a  transition  strategy  to  evolve  from  the  near-term 
(1978-1983)  IAS  architecture  to  the  mid-term  IAS  architecture. 

B.  Background.  In  July  1974,  the  General  Accounting  Office 
(GAO)  published  a  report  that  was  critical  of  the  Department 
of  Defense  (DoD)  for  (1)  not  having  a  single  agency  responsi¬ 
ble  for  management  of  the  entire  AUTODIN  system  to  include 
AUTODIN  terminals;  (2)  for  a  poor  telecommunications  center 
consolidation  record;  and  (3)  for  duplication  of  effort  and 
proliferation  of  LDMX-type  AUTODIN  terminals  by  the  Military 
Departments  (MILDEPs)  and  DoD  Agencies.  The  GAO  recommended 
to  OSD/DTACCS  (now  ASD/C3I)  that  a  single  AUTODIN  manager  be 
appointed  to  resolve  the  problems  as  they  surfaced. 

In  February  1975,  OSD/DTACCS  acted  on  the  GAO  recommen¬ 
dation  by  tasking  the  Defense  Communications  Agency  (DCA) , 
in  coordination  with  Services/Agencies ,  to  develop  an  IASA 
on  a  terminal- to- terminal  basis  and  based  on  that  architec¬ 
ture  to  define  a  common  family  of  AUTODIN  terminal  hardware 
and  software. 

In  December  1975,  OSD/DTACCS  approved  the  DCA  IASA 
development  plan  which  would  address  the  backbone,  concen¬ 
trators,  and  terminals  as  a  single  integrated  system  with 
processing  functions  allocated  to  system  components  on  the 
basis  of  how  and  where  they  can  best  be  performed.  As 
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a  result  of  this  plan,  DCA  is  responsible  for  accomplishing 
three  objectives:  (1)  develop  a  system  architecture  on  a 
terminal- to- terminal  basis;  (2)  develop  terminal  specifi¬ 
cations;  and  (3)  develop  related  standards,  formats,  and 
procedures. 

As  an  outgrowth  of  the  OSD  tasking,  JCS  Memorandum  of 
Policy  165,  titled:  AUTODIN  and  Associated  Message  Processing 
Systems ,  was  issued  on  5  May  1976.  Mop  165  establishes 
AuTODIN  as  the  DoD  common-user  data  communications  system, 
directs  maximum  use  of  the  system  elements,  identifies 
criteria  for  interservice  telecommunications  center  consoli¬ 
dation  and  automation,  provides  safeguards  to  prevent  pro¬ 
liferation  of  non-standard  terminal  systems,  and  provides 
policy  and  guidance  for  use  of  new  equipments  using  automation 
techniques  through  the  AUTODIN. 

In  December  1977,  DCA  completed  its  first  IASA  Report 
(Part  I)  which  identified  near-term  (1978-1983)  AUTODIN 
implementation  alternatives  and  recommendations. 

In  October  1978,  ASD/C3I  approved  the  IASA  Report  approach 
and  directed  DCA  to:  (1)  identify,  develop  and  promulgate 
necessary  standards;  (2)  identify  the  roles  and  relationships 
of  components  of  the  Integrated  AUTODIN  System;  (3)  establish 
an  Inter-Service/Agency  AMPE  Program;  and  (4)  complete  the 
development  of  functional  specifications  for  a  common  family 
of  terminals. 

C.  Organization.  The  IASA  Project  organization  is  shown  in 
Figure  1.  Control  of  the  project  is  exercised  through  the 
AUTODIN  Systems  Integration  Branch  (Code  534) ,  Headquarters 
DCA.  Technical  support  is  provided  by  the  Defense  Communi¬ 
cations  Engineering  Center  (DCEC) .  Representatives  of  the 
DCA,  MILDEPs,  National  Security  Agency  (NSA) ,  Defense  Intelligence 
Agency  (DIA) ,  and  Defense  Logistics  Agency  (DLA)  are  formed 
into  a  Technical /Policy  Panel  which  serves  as  the  forum  for 
discussion  of  IASA  issues.  In  addition,  there  are  three 
working  groups,  each  chaired  by  DCA,  with  participation  from 
MILDEPs  and  DoD  Agencies . 

The  IASA  Project  working  groups  were  established  to 
develop  the  required  design  baseline  inputs.  The  Security 
Working  Group  objective  is  to  insure  that  user  security 
requirements  are  factored  into  the  IASA  and  to  insure  that 
TEMPEST  criteria  are  considered  in  selecting  hardware  to 
implement  the  architecture.  The  User  Needs  and  Capabilities 
Working  Group  objective  is  to  develop  a  data  base  containing 


user  functional  requirements  and  capabilities  and  to  perform 
detailed  analyses  of  the  various  Automated  Message  Pro¬ 
cessing  Exchanges  (AMPEs)  and  terminals.  The  Standards  and 
Procedures  Working  Group  objective  is  to  develop  policy, 
procedures,  and  standards  for  message  preparation,  input, 
transmission,  output,  and  distribution  facilities. 
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D.  Scope.  This  report  presents  the  results  of  the  IAS 
Architecture  definition  process  as  it  applies  to  the  mid¬ 
term  (1984-1988)  time  period.  Previous  effort  in  this 
process  was  directed  toward  identification  and  analysis  of 
implementation  alternatives  for  the  near-term  (1978-1983). 

This  near-term  work,  described  in  the  IAS  Architecture 
Report  of  December  1977,  was  intended  to  shape  decisions  on 
the  implementation  and/or  use  of  existing  and  readily  available 
hardware/software  components  in  order  to  achieve  a  near-term 
enhanced  AUTODIN  system  capability.  The  mid-term  architecture 
analyses,  by  contrast,  were  directed  toward  the  definition 
of  an  overall  top  down  system  architecture  and  the  definition 
of  new  system  elements  required  to  support  this  architecture. 
This  report  identifies  the  roles  and  relationships  of  the 
IAS  components  and  addresses  such  topics  as  user  requirements, 
data  communications  trends,  standards,  allocation  of  functions, 
and  security. 

Based  on  ASD/C3I  guidance  and  overall  AUTODIN  system 
requirements,  the  major  architectural  objectives  relevant  to 
the  mid-term  are: 

.  Phase-out  AUTODIN  I  switches 
.  Standardize  terminals /AMPEs 

.  Reallocate  ASC  functions  to  new  IAS  elements 
Enhance  system  survivability 
.  Enhance  interoperability  to  tactical  and  allied 
forces 

.  Determine  allocation  of  new  functions 

.  Accomplish  the  above  objectives  via  evolution 

Consistent  with  these  objectives,  the  IAS  architecture 
definition  effort  over  the  past  year  has  been  to: 

Project  IAS  user  requirements  to  the  mid-term 
.  Define  viable  mid-term  candidate  architectures 

Evaluate  the  differences  among  architecture 
alternatives 

.  Define  the  role  of  the  Inter-Service/Agency  Automated 
Message  Processing  Exchange  (I-S/A  AMPE) 

.  Define  the  IAS  Security  subsystem 

.  Recommend  allocation  of  ASC  functions  among  IAS 
elements 

Recommend  a  preferred  mid-term  architecture 
Define  a  transition  strategy  from  the  near-term  to 
the  mid-term 


The  preferred  IAS  architecture  presented  in  this  report 
satisfies  all  of  the  major  objectives  for  the  mid-term.  In 
addition,  the  transition  approach  can  be  achieved  in  an 
orderly  evolutionary  process  from  the  near-term  to  the 
mid-term  and  eventually  into  the  far- term  integrated  AUTODIN 
system. 

The  IASA  Project  milestones  are  identified  in  Figure  2, 
which  logically  divides  the  project  into  three  parts.  The 
December  1977  TASA  Report  (Part  I)  provided  AUTODIN  imple¬ 
mentation  alternatives  and  recommendations  through  1983. 

This  report  (Part  2)  provides  architectural  alternatives  for 
the  period  1984  through  1988.  In  October  1979,  an  IASA 
(Part  3)  report  will  be  provided  to  include  standards  and 
functional  specifications  for  a  common  family  of  terminals. 
Reference  is  made  to  Appendix  1  for  list  of  acronyms. 
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SECTION  II 


REQUIREMENTS 


A.  General.  The  purpose  of  this  section  is  to  identify 
user  requirements  as  they  are  expected  to  exist  in  the  mid¬ 
term  (1984-1988)  and  to  assess  the  data  communi cat ions 
environment  of  the  1980's.  The  requirements  identified  in 
the  IASA  Report  (Part  I)  for  the  near-term  (1978-1983) 
remain  valid  for  the  purpose  of  determining  the  mid-term 
architecture  strategies.  In  addition  the  extent  to  which 
the  IAS  will  provide  increased  user  satisfaction  over  the 
AUTODIN  system  of  today  is  dependent,  in  part,  on  the  advancing 
state-of-the-art  in  technology  which  offers  considerable 
promise  of  increased  capability  at  reduced  costs. 

The  mid-term  IAS,  as  an  evolving  network,  will  be 
influenced  by  requirements  identified  within  on-going  Service/ 
Agency  actions  to  include  the  following  areas :  telecommunica¬ 
tion  center  consolidations,  Automatic  Message  Handling 
Systems  (AMHS) ,  Advanced  Research  Project  Agency  Network 
(ARPANET)  connectivity  to  AUTODIN  II,  WWMCCS  Intercomputer 
Networks  integration  into  AUTODIN  II,  AUTODIN  billing  structure, 
standards  and  the  interface  with  tactical  and  allied  forces. 
These  architectural  considerations  are  discussed  herein  as 
special  items. 

B.  Evolving  Data  Communications  Environment.  The  near-term 
IAS  results  from  evolutionary  developments  of  both  the 
existing  AUTODIN  I  and  developments  in  the  AUTODIN  II  program. 
During  the  near-term,  one  or  more  AUTODIN  I  Switching  Centers 
(ASCs)  will  be  closed.  Common-user  narrative/record  service 
to  DoD  components  worldwide  will  be  provided  by  a  network  of 
Service/Agency  AMPEs  and  terminal  equipments,  supported  by 
ASCs  connected  via  a  combination  of  AUTODIN  II  Packet  Switching 
Nodes  (PSN)  trunks  and  inter-ASC  trunks .  Interface  between 
AUTODIN  record/data  users  and  allied/tactical  users  will  be 
accomplished  by  designated  interfaces  to  the  NATO  Integrated 
Communications  System  (NICS) /Teletype  Automatic  Relay  Equipment 
(TARE)  and  the  TRI  TAC's  message  switches. 

For  planning  purposes,  a  near-term  1983  bcseline  archi¬ 
tecture  is  defined  in  order  to  provide  a  basis  for  mid-term 
(1984-1988)  transition  development.  This  baseline  archi¬ 
tecture  is  best  described  as  a  consolidated  network  consisting 


of  two  major  subsystems,  the  AUTODIN  I  narrative /record 
subsystem  and  the  AUTODIN  II  computer  communications  sub¬ 
system.  The  IAS  architecture  efforts  throughout  the  near- 
term,  however,  will  result  in  considerable  degree  of  sharing 
of  assets  between  these  major  subsystems  as  well  as  signifi¬ 
cant  standardization  of  user  terminals  and  local  message 
processing  equipments.  In  addition,  the  architectural 
developments  of  the  1979  to  1983  time  period  establish  the 
groundwork  for  the  integration  of  these  two  subsystems  that 
will  take  place  throughout  the  mid-term  time  period.  By 
1983,  eleven  to  fifteen  ASCs  should  be  in  operation  (seven 
overseas,  and  four  to  eight  in  CONUS).  Functionally,  the 
ASC  will  be  essentially  unchanged  from  what  exists  today. 

It  will  continue  to  provide  such  store-and-forward  functions 
as  message  retrieval,  intercept  storage,  multiple  address 
processing,  code  conversion,  and  format  conversion.  Also  by 
1983,  it  is  expected  that  eight  PSNs  will  be  in  operation 
(three  overseas,  and  eight  in  CONUS). 

The  near-term  IAS  architecture  provides  an  AUTODIN 
system  that  is,  in  general,  responsive  to  the  needs  of  both 
narrative/record  and  data  users.  On  the  other  hand,  the 
1983  baseline  architecture,  illustrated  in  Figure  3,  does 
not  represent  an  acceptable  conclusion  to  the  integration 
process.  Therefore,  the  need  for  continued  evolution  to  a 
mid-term  Integrated  AUTODIN  System  Architecture  is  clear. 

1 .  Major  Subsystems  of  the  Baseline  Architecture. 

a.  AUTODIN  I.  The  Automatic  Digital  Network 
(AUTODIN)  I  is  a  store  and  forward  switched  network  of  the 
Defense  Communications  System  (DCS)  which  functions  as  a 
single  integrated  worldwide,  high-speed,  computer-controlled, 
general  purpose  communications  network,  providing  secure 
record  communications  service  to  the  Department  of  Defense 
(DoD)  and  other  Federal  agencies,  AUTODIN  I  has  been  opera¬ 
tional  for  approximately  16  years  and  has  undergone  numerous 
enhancements  and  expansions  required  to  meet  the  growing  DoD 
requirements  for  data/record  communications.  In  addition, 
many  additional  enhancements  and  improvements  are  currently 
in  process  and/or  planned  for  the  AUTODIN  I  to  keep  it 
viable  and  responsive  to  the  needs  for  data/record  communica¬ 
tions  into  the  1980s. 

(1)  CONUS.  During  1976,  an  expanded  memory 
system  was  installed  at  all  eight  CONUS  ASCs  as  well  as  at 
the  Hawaii  ASC.  This  system  consists  of  four  disc  units  and 
two  mini- computers  at  each  switch.  Another  CONUS  AUTODIN 
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1983  BASELINE  ARCHITECTURE 
FIGURE  3 


support  project  is  the  replacement  of  the  magnetic  tape 
stations  and  mass  memory  units  with  disc  units  at  each  ASC. 

In  addition  to  significant  cost  savings,  this  enhancement 
provides  a  direct,  high-speed,  channel  inter-connect  to  the 
AUTODIN  II  PSNs  and  will  permit  use  of  PSNs  for  digital 
trunking  between  ASCs. 

(2)  Overseas.  To  meet  current  forecasted 
operational  requirements  and  to  replace/refurbish  worn  out 
subsystems  of  the  overseas  AUTODIN  I,  DCA  has  also  initiated 
several  enhancement  projects.  These  are:  memory-memory 
control  replacement;  input/output  controller,  card  reader, 
and  high-speed  printer  replacement;  magnetic  tape  subsystem 
replacement;  and  patch  and  testing  facility  upgrade.  These 
enhancements,  to  be  completed  by  December  1980,  will  insure 
operation  of  the  overseas  AUTODIN  through  at  least  1985. 

b.  AUTODIN  II.  The  AUTODIN  II  is  a  general  purpose 
data  communications  packet  switched  network  for  integrating 
the  teleprocessing  and  record  communications  needs  of  DoD 
into  a  single  digital  backbone  system.  The  system  will 
employ  a  short  data  handling  unit  or  packet  of  bits  to 
accommodate  man- computer ,  computer-computer  and/or  computer- 
terminal  data  traffic.  Each  AUTODIN  II  PSN  will:  route  and 
distribute  packetized  traffic  (interactive,  query-response, 
record,  and  bulk- data)  over  a  full  duplex  wi de-band  trunking 
network;  electrically  interface  with  the  AUTODIN  I  system 
through  CONUS  ASCs;  terminate  up  to  200  lines  (both  individual 
and  multiplex)  per  switch  with  a  capability  to  service  up  to 
several  hundred  data  subscribers;  and  accommodate  dial-up 
access  lines  for  low  volume  subscribers  and  emergency  restora¬ 
tion.  As  a  major  subsystem  of  the  DCS,  AUTODIN  II  must 
provide  data  service  at  all  levels  of  security  from  unclassified 
to  Top  Secret,  Special  Intelligence.  To  meet  this  need,  the 
AUTODIN  II  communication  links  and  switch  facilities  will  be 
secured  to  the  highest  classification  level  transmitted,  and 
will  be  capable  of  being  compartmented  by  use  of  trans¬ 
mission  control  codes  and  virtual  logical  channels.  Each 
data  packet  will  be  verified  as  to  the  authorized  security 
level  and  community- of- interest  of  both  the  sender  and 
receiver . 


(1)  CONUS.  Initially  AUTODIN  II  Phase  I  will 
consist  of  three  PSNs  at  Ft.  Detrick,  Tinker  AFB,  and  McClellan 
AFB  with  a  Network  Control  Center  at  Headquarters  DCA.  The 
acceptance  of  this  three  node  network  establishes  the  FY 
1980  Initial  Operational  Capability  (IOC).  Subsecuently ,  a 
fourth  PSN  will  be  added  at  Gentile  AFB.  The  growth  of  the 
network  from  that  point  will  depend  on  user  requirements  and 
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user  ability  to  provide  the  software  and  hardware  interfaces 
needed  to  connect  to  the  network.  It  is  envisioned  that  the 
network  service  will  grow  incrementally,  as  required,  to 
meet  additional  requirements. 

(2)  Overseas.  AUTODIN  II  Phase  II  is  defined 
as  the  overseas  portion  of  the  PSN  implementation  scheme. 

An  IOC  of  FY  1981  has  been  identified  in  the  DCS  Five  Year 
Program  (FYP)  1981  for  providing  AUTODIN  II  service  on  a 
worldwide  basis.  With  the  validation  of  overseas  user 
system  requirements,  it  is  expected  that  the  location  of 
PSNs  overseas  will  be  cost-effective.  Identified  to  date 
are  twenty- three  Service/Agency  subscribers  of  CONUS  PSNs 
that  have  various  hosts  and/or  terminals  in  overseas  loca¬ 
tions.  Initially,  these  overseas  subscribers  will  be  connected 
to  CONUS  based  PSNs  by  use  of  multiplexers  or  concentrators 
in  order  to  reduce  access  line  costs. 

2.  Baseline  Architectural  Elements.  Major  architectural 
elements  are  derived  from  AUTODIN  I  and  II  subsystems  and 
are  described  in  the  following  paragraphs. 

a.  Packet  Switch  Node  (PSN).  The  PSN  is  being 
developed  under  the  AUTODIN  II,  Phase  I  program  to  provide 
backbone  switching  for  both  the  AUTODIN  II  and  AUTODIN  I 
subsystems.  A  simplified  functional  block  diagram  of  the 
PSN  is  illustrated  in  Figure  4. 

As  indicated  in  this  figure,  the  PSN  includes  the  following 
major  subsystems : 

(1)  Line  Control  Module  (LCM) .  The  LCM  provides 
the  communications  interface  and  protocol  functions  necessary 
to  interface  to  trunks  as  well  as  host  computers  and  terminals 
terminated  at  the  PSN.  The  LCM  transfers  data  to  and  from 
trunks  in  the  form  of  packets,  to  and  from  host  computers 

and  other  binary  format  terminals  in  the  form  of  binary 
segments,  and  to  and  from  character  oriented  terminals  in 
the  form  of  characters.  The  LCM  exchanges  data  with  the 
Switch  Control  Module  in  the  form  of  both  packets  and  segments 
as  needed. 

(2)  Switch  Control  Module  (SCM) .  The  SCM  per¬ 
forms  the  basic  packet  switching  function  within  the  PSN. 

The  SCM  accepts  binary  segments  or  packets  from  the  LCM, 
processes  the  routing  and  control  information  contained  in 
the  data,  and  returns  packets  or  segments  to  the  LCM. 


PACKET  SWITCH  NODE 


(3)  Terminal  Access  Control  (TAC)  Module.  The 
TAC  is  included  in  the  PSN  to  permit  character  oriented 
terminal  subscribers  (both  AUTODIN  I  and  II)  to  use  the  PSN. 
The  TAC  includes  a  Terminal  Handler  Protocol  (THP) ,  Trans¬ 
mission  Control  Protocol  (TCP)  and  a  Segment  Interface  Pro¬ 
tocol  (SIP)  ,  which  allow  conversion  between  character  format 
data  and  binary  segment  data  for  processing  by  the  SCM.  The 
TAC  capability  of  the  PSN  can  be  implemented  outside  the  PSN 
itself  at  remote  terminal  or  host  locations.  In  this  case 
the  remote  TAC  interface  to  the  PSN  is  in  binary  segment 
format . 


b.  AUTODIN  Switching  Center  (ASC) .  The  1983  baseline 
architecture  should  consist  of  eleven  to  fifteen  AUTODIN  I 
switching  centers  (four  to  eight  leased  in  CONUS  and  seven 
overseas)  and  eleven  AUTODIN  II  PSNs  (eight  in  CONUS  and 
three  overseas).  ASCs  will  terminate  local  subscribers  and 
also  terminate  remote  subscribers  via  the  PSN  backbone. 

Direct  trunks  between  ASCs  will  be  used  to  provide  connecti¬ 
vity  among  allied/tactical  users,  overseas  ASCs  and  ASCs 
colocated  with  PSNs. 

c.  Automated  Message  Processing  Exchange  (AMPE) . 

The  1983  architecture  will  include  Service /Agency  operated 
AMPEs,  such  as  the  AMMF. ,  LDMX,  NAVCOMPARS,  AF  AMPE,  and 
Streamliner.  These  AMPE  equipments  will  provide  local 
message  processing  and  communications  concentrator  functions 
for  narrative/record  users.  AMPEs  will  continue  throughout 
the  near-term  to  be  homed  on  designated  ASCs,  either  through 
direct  ASC  termination  or  through  a  TAC  interface  at  a  PSN. 

d.  Inter- Service /Agency  (I-S/A)  AMPE.  Toward  the 

end  of  the  near-term,  about  1982,  some  degree  of  AMPE  standard¬ 
ization  will  be  achieved  through  the  introduction  of  a  I-S/A 
AMPE.  This  near-term  network  element,  while  not  capable  of 
performing  all  AMPE  functions  ,  will  perform  a  subset  of  func¬ 
tions  including  all  the  basic  functions  to  provide  standard 
services  to  its  subscribers.  It  will  terminate  both  narrative/ 
record  and  some  small  ADP  computer  subscribers  and  be  homed  on 
an  ASC  and  terminated  either  on  that  ASC  or  a  PSN.  (If  termin- 
nated  on  a  PSN  the  traffic  will  be  handled  on  a  cut-through 
basis  to  the  home  ASC.)  Additional  information  on  the  upgrading 
necessary  for  the  mid-term  is  provided  later  in  the  report. 

e.  Host  Computers.  Major  high  volume  computer 
facilities  in  the  Service/Agency  communities,  such  as, 

WWMCCS  and  SACDIN,  will  interface  directly  to  PSNs  in  the 
near-term  architecture.  These  host  computers  are  centers  of 
major  Automatic  Data  Processing  (ADP)  activities  and  will 
provide  a  major  source  of  network  traffic;  low  volume  ADP 
facilities  may  be  connected  to  ASCs  or  PSNs  in  a  standard 


mode  or  connected  to  AMPEs  either  in  a  standard  or  subscriber 
specified  mode;  large  volume  ADP  facilities  should  be  connected 
directly  to  PSNs . 

f.  Terminals.  A  wide  variety  of  terminals  will 
exist  in  the  1983  baseline  architecture.  Typical  character¬ 
istics  of  the  AUTODIN  I  and  AUTODIN  II  terminals  anticipated 
in  this  period  are  shown  in  Table  1.  These  terminals  are 
defined  as  character  oriented  devices  capable  of  conducting 
a  single  conversation  and  range  from  teletypewriters  through 
software  programmable  computers. 

TABLE  1 


BASELINE  ARCHITECTURE  TERMINAL  CHARACTERISTICS 

Existing  AUTODIN  I  Anticipated  AUTODIJ’  II 

Terminals  Terminals 


Types  Teletypewriter,  card, 

magnetic  tape,  facsimile, 
multi-media,  computer 
interface  AMPE 


Teletypewriter,  card 
magnetic  tape,  facsimile, 
CRT,  sensor,  multi-media, 
host  computer 


Protocols  I,  II  and  V 
Modes 

Codes  ASCII,  ITA#2 


I,  IB,  1IA,  VI  Link 
Protocols  and  end-to- 
end  host  protocols 

ASCII,  Others  (Trans¬ 
parent  to  network) 


Speeds  45  thru  4800  bps  110  bps  thru  56K  bps 

Formats  JANAP  128,  ACP  127  Binary  and  character 

segment  formats,  message 
formats  transparent  to 
network. 

g.  Multiplexers.  Multiplexers  will  be  used  in  the 
baseline  architecture  wherever  practical  in  order  to  effect 
transmission  efficiency  and/or  cost  reduction. 


h.  Baseline  Architecture  Connectivity.  The  major 
interfaces  that  will  exist  in  the  baseline  architecture  are 
illustrated  in  Figure  5.  The  basic  link  protocol  and  inter 
face  characteristics  of  this  architecture  are  described  in 
Table  2. 
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baseline  architecture  connectivity 
FIGURE  5 


TABLE  2 


BASELINE  INTERFACE  CHARACTERISTICS 


CONNECTION 

LINK  PROTOCOL 

PSN-PSN 

Binary  Packet 

PSN-ADP  Host 

Mode  VI 

PSN-ASC 

Mode  VI 

PSN-Terminal 

Mode  I,  IB,  II  or  VI 
Character  via  Terminal 
Access  Controller  (TAC) 

PSN-AMPE/ Terminal 

Mode  I  (via  TAC) 

ASC-ASC 

Mode  I  (Switch  to 

Switch) 

ASC/AMPE-Terminal 

Mode  I,  II,  V 

ASC-NICS  (TARE) 

Mode  I 

ASC-AN/TYC-39 

Mode  I 

(1)  Tactical/NATO  Interfaces.  These  interfaces 
are  provided  through  the  AN/TYC-39  Automatic  Message  Relay 
developed  under  the  TRI-TAC  program  and  the  NATO  Integrated 
Communications  System  Teletype  Automatic  Relay  Equipment 
(NICS/TARE) .  Interface  to  both  of  these  systems  will  be 
accomplished  via  direct  connection  to  designated  ASCs. 

Overseas  both  the  AN/TYC-39  and  the  NICS/  TARE  interface 
will  be  accomplished  through  designated  ASCs.  In  CONUS  one 
or  more  of  the  colocated  ASC/PSN  sites  will  be  designated  as 
the  NATO  interface.  It  is  anticipated  that  both  the  NICS/TARE 
system  and  the  AN/TYC-39  relay  will  employ  an  AUTODIN  I, 

Mode  I,  terminal  interface  and  that  this  protocol  will 
provide  the  basic  access  mechanism. 

(2)  Security.  The  1983  baseline  architecture 
will  depend  upon  link-by-link  encryption  similar  to  that 
employed  in  the  current  AUTODIN  I  system. 

i.  Summary.  The  baseline  architecture  of  1983  will 
provide  an  AUTODIN  system  that  is,  in  general,  responsive  to 
the  needs  of  both  narrative/record  and  data  users.  In 
defining  the  next  major  evolutionary  step  toward  the  Integrated 


AUTODIN  System  in  the  mid-term,  the  following  characteristics 
of  the  baseline  architecture  should  be  considered: 

(1)  The  architecture  of  1983  represents  a 
consolidation  of  two  essentially  independent  networks  with 
significant  sharing  of  backbone  assets  and  two  co-existing 
user  communities  with  discrete  operating  procedures,  access 
arrangements  and  equipment  inventories. 

(2)  The  architecture  of  1983  represents  an 
increase  in  the  standardization  of  AMPE  and  terminal  operation/ 
configuration  through  introduction  of  Inter- Service/Agency 
AMPEs. 

(3)  The  AUTODIN  system  of  1983  will  provide 
significantly  improved  performance  and  service  for  data 
users  through  the  capabilities  of  the  AUTODIN  II  subsystem. 

(4)  The  architecture  of  1983  represents  little 
improvement  in  system  survivability,  security,  or  operational 
flexibility  over  the  current  AUTODIN  I  system  for  narrative/record 
users . 

(5)  The  AUTODIN  system  of  1983  represents  improve¬ 
ment  in  cost  effectiveness  as  a  result  of  the  closure  of 

one  or  more  CONUS  ASCs  and  consolidation  of  ASC  and  PSN  sites. 


As  a  result  of  these  and  other  architectural  considerations, 
the  baseline  architecture  does  not  represent  an  acceptable 
conclusion  to  the  integration  process.  Therefore,  there  is 
need  for  a  continued  evolutionary  approach  to  the  mid-term 
Integrated  AUTODIN  System  Architecture. 

3.  Trends . 

a.  General.  Based  on  current  DoD  experience  with 
new  technology  introduction,  and  the  development  cycle 
required  for  communications  system  implementation,  new 
network  elements  to  be  introduced  during  the  mid-term  should  be 
based  upon  available  technology.  This  precludes  the  introduction 
during  the  mid-term  of  two  of  the  principal  long-term  architectural 
objectives  identified  in  previous  studies,  i.e.,  integrated 
voice  and  data  and  the  use  of  multiple  access  satellite  broadcast 
capability.  However,  the  long-term  promise  of  these  technologies 
and  the  probability  of  their  successful  development  cannot  be 
ignored.  Therefore,  these  advanced  technologies  are  assumed  to 
be  available  for  far- term  (post  1988)  IAS  implementation.  In 
addition,  the  mid-term  architecture  definition  will  consider  the 
impact  of  this  eventual  far- term  evolution  on  the  mid-term 
architecture  Itself,  and  thereby  not  preclude  successful  con¬ 
tinued  evolution  of  the  IAS. 


b.  Technology  Trends.  The  predominant  trend  in 
telecommunications  relevant  to  the  DCS  is  an  evolution 
toward  digital  transmission  and  switching  in  the  1980s.  The 
basic  technology  which  has  spurred  the  acceleration  of 
digital  switching  is  the  Large  Scale  Integrated  circuit 
technology.  Microprocessors,  semiconductors  and  magnetic 
bubble  memories,  phased  logic  arrays,  and  custom  tailored 
chips  have  dramatically  reduced  hardware  cosfs,  decreased 
equipment  size,  and  improved  reliability  and  maintainability 
of  telecommunications  equipment.  The  nature  of  fiber  optics 
lends  itself  more  suitably  to  digital  operation  and  this 
technology  is  rapidly  making  inroads  in  short  haul  and 
exchange  area  communications  in  the  United  States.  Satellite 
communi cat ions  technology  continues  to  make  impressive  gains 
in  cost  and  size  of  satellite  terminals  operating  at  higher 
frequency  ranges.  The  trend  here  is  also  towards  increased 
digital  operation.  Progress  in  digital  computer  technology 
has  dwarfed  developments  in  analog  computer  technology  and 
has  direct  influence  on  AUTODIN  as  well  as  indirect  impact 
on  other  aspects  of  the  DCS  such  as  system  control  and 
automated  operation.  These  trends  have  influenced  AUTODIN 
planners  to  consider  structures  where  the  intelligence  of 
switching  functions  such  as  control,  signaling,  and  protocols 
is  physically  located  closer  to  the  user  and  away  from 
backbone  nodes. 

c.  Economic  Trends.  Implementation  of  programs  to 
upgrade  the  DCS  is  constrained  by  the  DoD  budget  and,  in 
particular,  that  portion  of  the  DoD  budget  which  supports 
the  DCS.  A  second  constraint  is  the  amount  of  service  or 
new  equipment  that  can  be  procured  for  the  available  funds. 

A  third  constraint  is  the  manpower  available  to  operate  the 
DCS. 


(1)  Funding  Trends.  Projection  of  current 
trends  indicates  that  the  percentage  of  the  DoD  budget 
available  for  telecommunications  will  decrease.  While  the 
funds  available  for  the  portion  of  the  budget  relevant  to 
the  DCS  is  expected  to  grow  at  a  rate  comparable  to  the 
inflation  rate,  leased  charges  are  at  present  climbing  at 
higher  than  the  inflation  rate.  A  constrained  economic 
environment  is  projected  for  the  DCS  during  the  mid-term 
time  frame . 


(2)  Trends  in  Tariffs.  In  overseas  areas, 
tariff  charges  must  be  paid  in  the  currency  of  the  host 
country.  For  example,  the  German  and  Japanese  currencies 
relative  to  the  U.S.  currency  have  risen  30  and  407.  respectively 
during  the  period  from  January  1977  to  January  1979. 

(3)  Trends  in  Manpower  Availability.  DoD  manpower, 
military  and  civilian,  is  projected  to  remain  approximately 
level  in  the  immediate  future.  However,  data  from  the 
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Army  and  Air  Force  obtained  on  the  Frankfurt-Koenigstuhl- 
Vaihingen  (FKV)  digital  subsystem  over  a  one  year  period 
indicates  that  maintenance  men  are  not  required  on  a  24-hour 
basis  because  of  the  extremely  high  reliability  and  maintain¬ 
ability  of  the  new  equipment.  As  a  result,  some  of  the 
functions  of  maintenance  and  technical  controls  are  being 
combined  for  operating  the  Digital  European  Backbone. 

d.  Security  Trends.  The  maturity  and  availability 
of  various  security  technologies  during  the  IAS  mid-term 
will  be  a  major  factor  in  achieving  the  system  security 
goals.  These  technologies  include  not  only  new  cryptographic 
and  communications  security  techniques  but  also  computer 
software  security  and  access  control/authentication  techniques . 
The  following  paragraphs  discuss  the  major  technological 
advances  applicable  to  the  design  and  development  of  secure 
systems . 


(1)  Background.  Based  upon  studies  sponsored 
by  the  Air  Force  in  the  early  1970s,  a  model  of  a  secure 
system  was  developed-- the  Reference  Monitor  (Figure  6).  The 
Reference  Monitor  is  a  model  of  the  operating  characteristics 
of  a  hardware/software  system  whose  purpose  is  to  control 
the  relationship  between  subjects--users  of  a  system  resource, 
and  objects-members  of  a  set  of  system  resources.  It  is  the 
function  of  the  Reference  Monitor  to  mediate  every  attempt 
by  a  subject  to  access  an  object.  In  response  to  this 
security  concept,  several  software  based  prototype  systems 
were  developed  which  confined  to  a  small  portion  of  code  the 
security  relevant  decisions  concerning  resource  allocation. 
These  implementations  of  the  Reference  Monitor  have  come  to 
be  known  as  security  "kernels.”  Since  these  initial  studies, 
considerable  effort  has  gone  into  developing  security  kernels 
and  operating  systems  for  various  systems.  The  following 
chronological  list  illustrates  some  of  the  more  important 
events : 


1971-1975;  Bell  Labs  UNIX  Operating  System 
developed. 

1973- 1975;  MITRE  developed  a  prototype 
security  "kernel"  on  PDP  11/45  and  applied 
the  concept  to  the  MULTICS  design. 

1974- 1975;  UCLA  developed  a  security  "Kernel" 
architecture  emphasizing  a  virtual  machine 
monitor  with  a  goal  of  ^kernel"  verification. 
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FIGURE  6 


1975;  MITRE  and  UCLA  began  adapting  their 
kernels  to  support  a  prototype  secure 
operating  system  compatible  with  UNIX. 

SDC  began  development  of  kemelized  version 
of  IBM  VM  370  operating  system. 

1977;  SRI  developed  formal  specifications 
for  a  Probably  Secure  Operating  System 
(PSOS). 

1977;  ARPA  began  to  develop  a  production 
quality  version  of  the  secure  UNIX  System 
called  the  Kemelized  Security  Operating 
System  (KSOS) . 

1978;  KSOS  design  phase  completed.  The 
implementation  phase  is  being  accomplished 
by  Ford  Aerospace  and  Communications  Corpo¬ 
ration  (FACC) . 


(2)  Security  Reference  Monitor  Models.  In 
order  to  define  the  Reference  Monitor,  system  security 
behavior  is  designed  to  conform  to  a  formal  definition  of 
security.  Several  models  have  been  developed  based  on 
abstract  mathematics  which  form  the  starting  point  of  a 
verifiable  secure  design.  These  models  include  MITRE's 
Security  Kernel  Model  and  Stanford  Research  Institute's 
Hierarchical  Development  Model. 

(3)  Verifiable  Secure  System  Design.  Once  the 
behavior  of  the  abstract  system  has  been  proven  with  respect 
to  security,  the  translation  to  a  usable  system  must  be 
accomplished  in  a  manner  that  insures  the  final  implementation 
can  be  certified.  A  validation  chain  such  as  the  one  illus¬ 
trated  in  Figure  7  allows  the  design  to  proceed  in  small 
steps  with  each  link  in  the  chain  representing  the  final 
implementation  at  different  levels  of  detail.  Specific 
validation  procedures  are  applied  in  each  step.  The  formal 
specification  stage  describes  the  functional  layers  and 
State  environments  of  each  of  the  abstracted  modules  of  the 
Reference  Monitor.  The  algorithmic  or  program  development 
stage  is  a  representation  of  the  specified  abstraction  in  a 
suitable  high  order  language.  The  difficult  portion  of  this 
step  is  that  the  security  relevant  programs  must  be  proven 
correct  so  that  ultimate  certification  of  the  machine  code- 
the  final  step  in  the  chain-will  assure  the  protection  of 
classified  information. 
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(4)  Security  Kernels.  In  order  for  a  software 
security  kernel  to  provide  "security",  the  kernel  must 
implement  the  Reference  Monitor  controls  by  mediating  every 
access  by  a  subject  to  an  object.  In  addition,  the  kernel 
must  be  isolated  to  protect  against  unauthorized  modification. 
Finally,  the  security  properties  of  the  kernel  must  be 
verifiable.  There  are  several  advantages  to  the  security 
kernel  approach,  especially  in  a  communications  system 
environment.  First,  the  security  code  is  essentially  put  at 
the  innermost  or  lowest  level  of  the  system.  Therefore,  it 
does  not  depend  on  other  code  for  its  correct  operation,  and 
the  non-security  related  parts  of  the  system  can  be  modified 
with  no  effect  on  the  kernel.  Second,  the  kernel  may  be 
small  enough  with  respect  to  the  number  of  lines  of  codes 
that  it  can  be  verified  as  correct  with  respect  to  a  proven 
security  model. 


(a)  The  goal  of  the  KSOS  effort  is  to 
develop  a  computer  operating  system  compatible  with  the 
proprietary  UNIX  operating  system,  which  supports  multilevel 
security.  The  design  of  KSOS  consists  of  a  software  kernel 
that  supports  the  full  facilities  of  an  operating  system 
capable  of  controlling  multilevel  secure  processes.  The 
kernel  implements  the  security  rules  and  mediates  the  inter¬ 
action  between  subjects  and  objects  based  upon  these  rules. 
Although  the  initial  implementation  is  targeted  for  the  PDP 
11/70,  the  KSOS  design  is  being  written  in  a  systems  level 
high  order  language  (HOL)  called  EUCLID,  which  was  designed 
to  facilitate  verification.  Furthermore,  the  specification 
of  KSOS  in  a  high  order  language  makes  it  more  transportable 
to  other  processors.  A  matrix  which  illustrates  character¬ 
istics  of  KSOS  and  several  other  important  security  kernel 
efforts  is  shown  in  Table  3.  KSOS  is  the  primary  security 
kernel  candidate  for  use  in  the  relevant  IAS  network  elements 
and  user  interface  controllers.  This  assumption  is  based 
upon  the  intended  applications  of  a  verified  KSOS  and  the 
1980  timeframe  in  which  good  design  prototypes  should  be 
available  for  evaluation  and  inclusion  into  the  IAS  design 
specifications. 


(b)  NSA  has  benefited  from  previous  and 
opgoing  software  security  R&D  efforts.  The  BLACKER  UNIX 
kernel  is  a  modified  version  of  the  UCLA  UNIX,  and  the 
BLACKER  kernel  basically  supports  the  communications  environ¬ 
ment  of  the  BLACKER  I  prototype  systems.  The  secure  version 
of  the  IBM  VM  370  being  developed  by  Systems  Development 


MATRIX  OF  SECURITY  KERNEL  CHARACTERI 


ft)  e 

>  x 

CO  O' 

M  -9  «-*  ft  ~ 

ac  &*-*•—» 

<  -H  X  W 

X  W-  J  ft  0 

h3  <H  *-< 

Oft  y  C  w 

p  o  *  p 

ft  ■*  >  « 

u  «  to  a. 


»  >>  > 
tO  X  X 
=3  4) 

H  >S  -O  -i 

<  — <  4)  .a 

H  w  a  •* 

to  cow: 


l 

00  o 

C  C  P  c 

•H  (x  ^ 

ft  ft) 

X  T3  Oft  X)  ^ 
ft)  W  ft 

^  w  Oft  o  c 

»-i  C  O  W  O 

W  ft)  <  4* 

c  e  «o  ft)  w 

ft)  ft)  00  Cl  ft 

«  *-*  V  P  O' 

ft)  a  ft  w  ai  r^. 

p  e  x  o  a  o 


3  41  od 

U  T3  U  C 


P  *  < 

ft)  0)  — - 

u  m  CO 

C  0}  I 
«-  C  w  •_ 

X  ft* 

®  JC  * 

C  J*  U  - 

o  t  «  « 

Ti  o  a  • 

w  1  ft  ft 

ID  U  4  Z 

oft)  a  to 

■H  C  4)  ft)  a. 

c  OCX 
9  ft  ft  t>  - 

E  u  ®  w  w 

e  u  ®  -h  cl 

O  ft  ft  »  X 

u  l.  e  in  < 


ec 
U3 

C  Oft  ft)  *~ 

H  U  >  -O  z 

ft  <  ft  ft  :=> 

J  T3  w 
so  a 


p  -o  w  e 

p  a>  o  c  c 

o  o  a  E  **- 


I  i 

E  -H 

®  O  o  * 
k-uw.tr: 
ft)  w  U 
•-  C  bC 
r-*  0)  O  (J 
O  ft*  U  < 


* 

1 

ft 

•o  W- 

c 

c 

ft 

ft  •*« 

ft 

o 

> 

P  P 

p 

•H 

ft 

C  ft 

p 

ft 

X 

ft  > 

9 

JP 

u 

E 

U 

ft 

ft 

to 

ft  ft 

> 

> 

o 

«— i  — 

ft 

P 

O.  — • 

ft 

r-t 

t» 

E  1 

x> 

ft 

■H 

«H  ft. 

e 

c 

p 

X 

o 

o 

9 

ft 

w 

C  CL 

•h 

> 

ft 

w 

>N 

to  C  x  o  U  w 


«H  c  P- 

U  ft)  o 

•H  E 

w  ft)  >s 

c  ^  « 
•<  C.X 


k-  ®  e 
ft)  -w  o 
> 

©  >.  tO 
ft)  r*  fH 
l  n  u 


9  C  X 
u  r  o> 

o  >  k-  *j 

®  p  ® 

w-  9  ft) 
<  O  u  w 


• 

c 

1 

0 

ft  E  P 

ft 

•H 

POO 

E 

ft 

ft  ft  Lm 

ft 

P 

p-  c 

4 J 

ft 

CO  ft* 

ft 

> 

U  ft 

>s 

— 

CO 

W 

#-  X  — 

ft 

•J  ft  ft 

c 

P 

9>  ^  ^ 

c  -*• 

ft 

X  -  ft 

—  CO 

> 

«  C 

*J  ►— 

ft 

<—  >  o 

ft  X 

CO 

O  ft  X 

E  ^ 

" 

BC  ft 

C  fc 

I 

TJ 

•*4 

0 

ft 

X  c 

L- 

c 

X* 

XJ 

c  — 

— 

ft 

C 

9  E 

p 

ft 

ft 

u- 

ft 

ft 

CL 

P 

> 

X 

E 

u 

CO  — 

o 

9 

u 

•— 

c 

u 

U 

y-  «— < 

ft 

c 

h-  ft 

E 

*- 

c 

ft 

X  > 

u 

u> 

ft 

X 

93  ft 

C 

ft 

ft 

X  - 

u 

X 

w 
O  C 
tei 

w 

ft 

<J 

ft 

ft 

CO 

AH 

ft 

u 

X  T5 

c 

p 

(ft* 

o  c 

9 

a> 

z 

CJ  ft 

e 

— • 

to 

JC 

p-  1 

p 

0  4-) 

O 

ft 

ft 

E 

C  9 

w 

00 

ft 

0  ft 

ft 

ft 

4_> 

«H 

C 

ft 

tr 

ft  to 

ft 

>s 

P  o 

CO 

ft 

« 

ft 

E 

>  o 

X 

o c 

1^- 

T) 

c 

ft  r-1 

p 

C 

•H 

P 

o 

ft 

ft 

eft)  u  r 

OX  -*  X 

— ■  *j  p  x  oc 

>s  w  a  ft  ft  -h 

ft)  c  w  W  h  X 
•w  >  -•  ft  C  — 

P  >s  D  ft)  9  E 

a®®  u  to  ft 

E  C  ft  ft  4- 

•h  o  E  O  ft  -ft 


k-  X  ft  P  ft  ^>  > 
CL  P  C  U  W  ft 


e  o  w  p 

ft  ft  >>  ft 

O  «  to  E 


ft  ft  *j  u 

co  x  ^  ®  o 


t Iona  . 


Corporation  (SDC)  is  an  excellent  candidate  for  Multilevel 
Security  (MLS)  IAS  hosts.  This  effort  is  currently  in  the 
coding  and  testing  stage  and  should  be  available  by  the  end 
of  1979. 

(5)  Software  Verification.  The  design  of 
security  into  IAS  processors  will  require  that  the  security 
behavior  of  the  system  be  verified.  Several  efforts 
directed  toward  the  specification  and  implementation  of 
secure  software  have  reached  the  stage  where  they  may  be 
applied  to  engineering  development  applications.  Systems 
such  as  AUTODIN  II,  KSOS,  Black -Crypto-Red  (BCR),  BLACKER, 

(see  paragraph  4  of  Appendix  4.)  etc.,  have  begun  to  apply 
these  technologies,  so  that  considerable  experience  should 
be  gained  in  time  for  application  to  the  mid-term  IAS.  The 
selection  of  a  specification  language  and  an  implementation 
language  for  the  IAS  secure  software  will  benefit  from  a 
detailed  evaluation  of  the  efforts  mentioned  above. 

(6)  Secure  Protocol  Design.  Experience  with 
the  design  of  major  communications  systems  requiring  security 
has  demonstrated  the  importance  of  security  consideration  in 
the  development  of  communications  protocols.  Considerations 

of  reliability  and  efficiency  have  already  led  to  a  realization 
of  the  need  for  improved  techniques  to  specify  and  ai.  alyze 
communication  protocols.  Improved  specification  techniques, 
such  as  finite  state  machine  representations,  have  begun  to 
receive  attention  in  the  research  community.  DCA  will  apply 
as  much  of  this  protocol  development  methodology  as  is 
practical  in  the  development  of  protocols  for  the  mid-term 
IAS. 

(7)  Advanced  COMSEC  Techniques.  AUTODIN  II 
will  initially  offer  subscribers  essentially  the  same 
security  capabilities  as  those  available  today  in  AUTODIN  I. 

The  baseline  security  capabilities  to  be  offered  by  AUTODIN 
II  using  conventional  COMSEC  techniques  are  listed  in 
paragraph  2  of  Appendix  4.  The  operating  and  maintenance 
costs  associated  with  providirg  this  security  capability  to 
AUTODIN  II  are  high.  These  costs  include  several  elements. 

"  .  Distribution  costs  associated  with  manual 

dissemination  of  keying  material. 

.  Maintenance  costs  associated  with  obsolete 
technology . 

Personnel  costs  associated  with  providing 
a  large  number  of  operation/maintenance 
personnel  with  security  clearances  for  the 
switches  and  crypto  devices . 
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Physical  security  costs  associated  with 
protecting  the  switches,  crypto  devices, 
and  keying  material. 

The  maintenance  costs  attributed  to  the  crypto  devices  can 
be  reduced  by  replacement  of  these  devices  with  modern, 
highly  reliable  link  key  generators  with  electronic  keying 
capability,  which  should  also  help  reduce  costs  associated 
with  distribution  and  storage  of  hard  copy  keying  material. 
However,  personnel/physical  security  costs  of  the  system 
would  be  largely  unaffected  and  the  security  deficiencies 
addressed  in  paragraph  2  of  Appendix  4  would  still  remain. 

C.  Mid-Term  Requirements  and  Operating  Environment.  The 
mid-term  architecture  for  the  Integrated  AUTODIN  System 
(IAS)  will  provide  an  architectural  framework  for  the  evolu¬ 
tionary  development  of  the  AUTODIN  during  the  period  1984- 
1988.  The  IAS  architecture  is  not  intended  to  represent  a 
new  system  that  must  be  developed  and  superimposed  on  existing 
common  user  DoD  systems  in  a  competitive  or  duplicative 
manner.  It  is  rather  intended  as  a  vehicle  to  guide  the 
evolution  of  DoD  data  telecommunications  towards  a  more 
secure,  survivable,  efficient,  and  cost  effective  means  of 
satisfying  both  narrative/record  and  data  communications 
requirements  throughout  the  1980-1990  timeframe.  This 
section  presents  the  projected  user  requirements  for  the 
mid-term  IAS  and  defines  the  anticipated  environment  in 
which  the  IAS  should  operate. 

1  AUTODIN  I.  Currently  installed  AMPEs  and  terminal 
equipments  of  the  AUTODIN  I,  as  well  as  those  installed 
during  the  period  1979-1983,  will  have  a  useful  life  extending 
into  (and  in  some  cases  through)  the  mid-term  time  frame. 

The  evolutionary  implementation  of  the  IAS  precludes  the 
wholesale  replacement  of  these  equipments  during  the  mid¬ 
term.  Therefore,  the  mid-term  architecture  must  provide  for 
support  of  AUTODIN  I,  Mode  I-V,  character  format  terminals  and 
AMPEs  throughout  the  mid-term  time  frame.  The  implication 
of  this  constraint  is  most  significant  upon  the  functional 
definition  of  the  nodal  elements  which  must  interface  these 
current  inventory  AUTODIN  I  AMPEs  and  terminals.  In  addition 
to  providing  the  link  protocols,  the  nodal  elements  required 
to  support  surviving  AUTODIN  I  subscriber  equipments  must 
also  provide  all  terminal  support  functions  formerly  provided 
by  the  ASCs.  This  has  the  effect  of  defining  the  minimum 
functional  capability  of  these  nodal  elements. 


a.  Traffic  Requirements.  Based  upon  current  traffic 
trends,  the  AUTODIN  I  traffic  growth  through  1980  is  projected 
at  5  percent  per  year  for  messages  and  11  percent  per  year 
for  lineblocks.  Since  some  computer  oriented  users  of 
AUTODIN  I  are  expected  to  convert  their  bulk  traffic  to 
AUTODIN  II,  a  decrease  in  the  rate  of  growth  in  AUTODIN  I 
traffic  is  expected  aft»»r  AUTODIN  II  is  implemented.  AUTODIN 
I  message  traffic  growth,  therefore,  is  projected  at  3 
percent  per  year  after  1980,  with  lineblocks  increasing  at  a 
rate  of  6  percent  per  year.  These  projections  result  in  aq 
total  AUTODIN  I  busy  hour  input  traffic  volume  of  1.2  x  10y 
bits  or  an  average  of  334  kbps  in  1988.  The  current  exchange 
of  information  between  users  of  the  AUTODIN  is  in  the  form 

of  narrative  text,  card  data,  and  magnetic  tape  data  message 
traffic.  Supporting  these  exchanges  are  the  formats  for 
entry  and  exit  from  the  switched  network  including  JANAP 
128,  JANAP  128  modified,  and  ACP  127. 

b.  Terminal  Requirements.  The  number  of  access 
lines  connected  to  AUTODIN  I  ASCs  has  remained  relatively 
constant  in  CONUS  and  overseas  for  the  period  1970  to  1978. 

The  number  of  AUTODIN  I  terminals  connected  to  the  network 
is  about  850  in  CONUS  and  450  overseas.  In  the  near-term 
the  trend  toward  relocation  of  terminals  as  remotes  to  AMPEs 
is  expected  to  offset  any  increases  in  user  requirements  for 
additional  terminals.  Therefore,  the  projected  AUTODIN  I 
subscriber  population  for  the  mid-term  is  estimated  at  850 
in  CONUS  and  450  overseas . 

2.  AUTODIN  II.  The  IOC  of  AU^ODIN  II  will  provide  4 
PSNs  with  option  for  additional  PSNs.  This  network  of  up  to 
8  PSNs  will  provide  the  backbone  for  the  mid-term  Integrated 
AUTODIN  System.  Based  on  an  IOC  of  December  1979  and  the 
advanced  degree  of  definition  of  network  operating  modes, 
protocols,  and  interfaces,  it  is  not  considered  feasible  to 
significantly  change  the  design  of  these  elements.  Therefore, 
the  mid-term  IAS  architecture  will  be  based  upon  use  of 
these  PSNs  with  minimum  essential  modifications. 

a.  Traffic  Requirements.  Preliminary  IAS  require¬ 
ments  estimate  the  total  AUTODIN  II  busy  hourQtraffic  input 
(exclusive  of  AUTODIN  I  traffic)  at  4.74  x  10y  bits  in  1982. 

A  rapid  growth  in  traffic  volume  to  this  level  can  be  expected 
as  subscribers  are  phased  into  the  system  between  mid-1980 
and  mid- 1982.  After  1982,  the  growth  will  probably  level 
off  to  that  of  a  mature  system.  The  increase  in  the  volume 
of  this  type  of  traffic  was,  therefore,  estimated  at  11 


percent  per  year.  The  AUTODIN  II,  Phase  I  System  Performance 
Specification  (Type  A)  provides  estimates  for  the  relative 
proportions  of  transaction  and  average  transaction  length  by 
traffic  type.  It  also  estimates  the  ratio  of  computer  to 
terminal  input  traffic.  These  estimates  were  used  to  derive 
traffic  volumes  by  transaction  type  and  subscriber  type. 

The  results  are  shown  in  Table  4. 

TABLE  4 

AVEPAGE  BUSY  HOUR  TRAFFIC  INPUT  FROM 
AUTODIN  II  TYPE  SUBSCRIBERS  (1988) 


Traffic  Type 
Narrati ve/Record 
Bulk 

Interactive  and  Query/ 
Response 

Total 


Input  Rate 


Terminals  (kbps) 
99 
207 

_ 5 

311  kbps 


Computers  (kbps) 
22 
2089 

36 

2158  kbps 


b.  Terminal  Requirements.  The  number  of  terminals 
(exclusive  of  AUTODIN  I)  and  host  computers  connected  to 
AUTODIN  II  PSNs  by  1982  is  estimated  to  be  approximately 
1300  and  150  respectively  based  on  current  validated  Service/ 
Agency  requirements.  The  rate  of  growth  in  AUTODTN  II 
terminals  and  computers  connected  to  the  network  beyond  1983 
is  dependent  on  many  factors  including:  user  data  processing 
requirements;  growth  of  distributed  processing  use  in  DoD; 
network  service  offerings;  and  Service/  Agency  policy.  There¬ 
fore,  it  is  unlikely  that  a  significant  number  of  new  requirements 
will  be  identified  and  validated  for  the  1984-1988  time 
period  immediately  following  the  AUTODIN  II  implementation. 

For  these  reasons,  a  modest  growth  rate  is  anticipated  for  the 
period  immediately  following  implementation.  The  projected 
1988  AUTODIN  II  total  terminal/host  population  based  on  this 
growth  rate  is  approximately  1800  terminals  and  host  computers. 

3.  Inter- Service/Agency  AMPE. 


a.  Definition.  The  I-S/A  AMPE  program,  as  defined 
in  the  December  1977  IASA  Report  (Part  I) ,  provides  for  the 
replacement  of  current  Service/Agency  AMPE  programs  by  1983. 


The  referenced  report  also  provided  the  architectural  pro¬ 
vision  for  including  AUTODIN  I  backbone  functions  in  an 
enhanced  I-S/A  AMPE.  In  a  recent  ASD/C3I  memorandum  the  DCA 
was  directed  to  establish  an  I-S/A  AMPE  program  as  an  initial 
step  toward  successful  implementation  of  an  Integrated 
AUTODIN  System.  The  DCA  has  since  developed  a  management 
approach  to  the  implementation  of  this  program  and  received 
ASD/C3I  approval. 

(1)  The  program  is  divided  into  two  phases. 

Phase  I  is  defined  as  the  near-term  basic  program  element, 
which  includes  the  majority  of  functions  now  performed  with¬ 
in  the  Services /Agencies  current  AMPE  programs.  Standard 
AMPE  functions  will  be  defined  and  developed  leading  to 
procurement  based  upon  joint  functional  specifications.  By 
this  phase  I  approach,  the  first  I-S/A  AMPE  should  be  fielded 
during  fiscal  year  1982.  Phase  II  is  defined  as  an  upgrading 
of  the  I-S/A  AMPE  developed  in  Phase  I  to  include  programming 
in  Ada  or  some  other  High  Order  Language,  provision  of  an 
AUTODIN  II  Mode  VI  interface  to  PSNs ,  a  Virtual  Message  Protocol 
allowing  I-S/A  AMPE  to  I-S/A  AMPE  interchange  of  message  traffic 
via  the  PSN  backbone,  a  remote  TAC  allowing  termination  of 
character  oriented  AUTODIN  II  subscribers,  and  adding  AMPE 
functions  not  provided  by  the  Phase  I  version.  In  addition, 
Phase  II  will  provide  the  capability  to  facilitate  the  phase 
out  of  the  ASCs  and  the  facilities  to  offer  new  network 
functions  and  services. 

(2)  In  developing  a  management  approach  to  this 
program,  AMPE  requirements  for  the  Air  Force  and  the  Defense 
Logistics  Agency  have  been  identified  which  cannot  be  met 
with  AMPE  hardware  currently  under  contract  and  other  require¬ 
ments  may  arise  before  1985.  The  Air  Force  has  the  majority 
of  such  requirements  identified  to  date  and  submitted  a 
management  plan  to  DCA  whereby  they  will  meet  all  new  Service/ 
Agency  AMPE  requirements  prior  to  1985. 

(3)  DCA  will  exercise  overall  management 
responsibility  for  system  development,  chair  the  Configuration 
Control  Board,  monitor  and  control  the  requirements  data 
base,  and  approve  specifications  to  insure  that  validated 
requirements  are  satisfied.  To  assist  in  the  implementation 
effort,  Air  Force  has  been  identified  as  the  DCA  agent  to 
work  with  the  other  Service/Agencies  to  define  requirements , 
acquire  hardware,  develop  application  software  based  upon 
their  available  macro  language,  and  other  system  functions. 
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(4)  The  capability  obtained  through  this  phased 
approach  is  responsive  to  user  needs  and  is  in  keeping  with 
ASD/C31  guidance  to  achieve  an  Integrated  AUTODIN  System  in 
an  evolutionary  manner. 

b.  Requirements.  During  the  mid- term *bime  period, 
the  majority  of  current  AMPE  equipments  installed  between 
1970  and  1980  will  reach  the  end  of  their  useful  life.  The 
new  Inter- Service /Agency  AMPE  will  be  used  to  replace  these 
AMPEs,  as  well  as  to  meet  new  AMPE  requirements.  In  addition, 
since  the  I-S/A  AMPE  will  be  functionally  capable  of  support¬ 
ing  Service /Agency  reouirements  at  all  security  levels,  a 
number  of  current  AMPE  sites  should  be  consolidated  through 
joint  use  of  the  I-S/A  AMPE.  In  order  to  project  the  total 
AMPE  and  I-S/A  AMPE  population  in  the  mid-term  IAS,  an 
analysis  of  current  and  planned  AMPE  sites  was  performed 
(See  Appendix  2).  Results  of  this  analysis  are  summarized 
in  Figure  8.  As  illustrated  in  this  figure,  total  population 
of  AMPE/I-S/A  AMPE  sites  will  peak  at  approximately  111  in 
1984  and  eventually  settle  to  less  than  109  in  1988.  It 
should  be  noted  that  this  represents  approximately  217.  less 
than  the  number  of  AMPE  sites  required  if  the  current  AMPE 
programs  were  extended  at  even  a  modest  4  percent  rate  of 
growth.  In  addition,  the  actual  number  of  AMPE  installations 
in  the  mid-term  will  be  based  upon  many  factors  not  considered 
in  this  analysis,  such  as  specific  S ervice/Agency  operational 
and  survivability  requirements.  The  results  of  this  analysis 
are,  therefore,  intended  only  to  support  the  architecture 
definition  process  and  are  not  proposed  as  a  replacement/ con¬ 
solidation  policy. 

4.  Terminals . 

a.  Definition.  A  user  terminal  is  that  input/output 
device  which  is  the  ultimate  source  and  destination  of  the 
data  traffic  being  handled  by  the  network.  All  intermediate 
sources  and  destinations  of  traffic  (e.g.,  an  AMPE)  are 
nodes  where  communications  services  are  performed.  Previously 
all  subscribers  directly  connected  to  ASCs  were  lumped 
together  as  terminals  without  regard  to  their  actual  hierarchi¬ 
cal  status.  Thus,  AMPEs  were  labeled  as  AUTODIN  terminals 
even  though  AMPEs  function  as  nodes,  not  user  terminals. 

(Note:  It  is  possible  that  some  devices  may  be  labeled  as 
AMPEs  which  perform  user  terminal  functions  in  addition  to 
the  normal  nodal  functions  associated  with  AMPEs.)  Depending 
on  functional  use  and  hierarchical  location,  such  a  device 


will  be  functionally  designated  as  either  a  node  or  a  user 
terminal.  Functional  specifications  for  a  "Common  Family  of 
AUTODIN  Terminals"  also  apply  to  AMPEs . 

b.  Requirements.  The  variety  of  terminal  equipments 
in  use  today  require  program  support  of  significant  degree 
considering  training,  maintenance,  software  support,  and 
logistics.  The  existence  of  multiple  terminal  programs  is 
due  to  differences  in  functional  requirements  and  the  existence 
of  competitive  equipment.  Since  not  all  terminals  have 
equivalent  capability,  it  has  been  necessary  for  the  Services/ 
Agencies  to  assume  program  responsibility  for  various  terminal 
equipments  to  ensure  the  spectrum  of  communications  require¬ 
ments  are  satisfied  cost-effectively.  A  corresponding  over¬ 
lap  in  the  functional  capability  of  competitive  equipment  is 
based  on  the  competition  for  government  dollars.  Consequently, 
the  Services/Agencies  have  been  afforded  the  opportunity  to 
be  selective  in  terminal  equipments,  tailoring  their  terminal 
to  precisely  meet  needs.  The  result  is  they  have  assumed 
program  responsibility  for  terminals  from  different  manu¬ 
facturers,  with  similar  capabilities  to  other  Service/Agency 
terminals . 

(1)  The  following  is  a  listing  of  known  pro¬ 
grams  developed  by  the  Services /Agencies  for  terminal  equip¬ 
ments  provided  by  level  of  message  processing  requirements. 
Reference  is  made  to  the  IASA  Report  (Part  I)  for  detailed 
information  on  terminal  requirements  within  the  four  levels 
specified. 

(a)  Level  I-Teletypewriter  (TTY)  equipment. 
Requirements  involving  only  narrative  traffic  at  low  speeds 
(asychronous)  are  satisfied  using  TTY. 

(b)  Level  II-Digital  Subscriber  Terminal 
Equipment  (DSTE) .  Requirements  for  card  and  narrative 
traffic  (Mode  I)  are  in  part  satisfied  by  the  DSTE. 

(c)  Level  Ill-Standard  Remote  Terminal 
(SRT) .  Requirements  for  terminals  servicing  as  input/output 
devices  directly  connected  to  AUTODIN  or  as  backside  remotes 
to  AMPEs  and  having  the  capabilities  of  narrative,  card,  and 
magnetic  tape  are  in  part  satisfied  by  the  SRT. 

(d)  Level  IV-Automated  Terminals.  Require¬ 
ments  involving  automation  of  processing  functions  for  card, 
narrative,  and  magnetic  tape  traffic  are  satisfied  by  a 
multitude  of  programs  to  include  AMPEs. 


(2)  Enroute  to  developing  terminal  specifications , 
for  application  in  tha  mid-term  time  period,  user  needs  and 
capabilities  have  been  profiled  within  the  four  terminal 
levels  in  order  to  highlight  potential  areas  for  standardi¬ 
zation. 


(a)  Level  1.  Separate  Service/Agency 
programs  for  replacement  of  aged  or  obsolete  TTY  equipment 
where  identified  to  the  JCS  as  candidates  for  development  of 
a  common  family  of  terminals.  Consistent  with  the  user 
needs  and  in  response  to  a  joint  ad  hoc  working  group  report 
(Replacement  of  Obsolete  TTY,  October  1978),  JCS  assigned 
the  Air  Force  as  the  Executive  Agent  for  the  replacement  of 
about  5200  obsolete  TTY  equipments.  In  addition,  the  JCS 
assigned  the  DCA  as  chairman  of  the  Joint  Terminal  Configura¬ 
tion  Control  Board  to  be  formed  after  the  validation  of  the 
Common  Family  of  Terminals  specifications.  This  joint 
program  direction  is  consistent  with  the  IASA  project  objectives 
and  satisfies  the  standard  terminal  functional  specifications 
for  Level  I  capability. 

(b)  Levels  II,  III,  &  IV.  To  provide  an 
orderly  process  in  developing  functional  specifications  for 
the  common  family  of  terminals  within  these  levels,  a  terminal 
characteristics  questionnaire  was  completed  by  the  Services/ 
Agencies . 


1.  In  the  three  levels  surveyed,  27 
systems  were  identified  and  data  collected  on  each.  These 
systems  exhibited  like  characteristics,  however,  the  survey 
did  point  out  some  differences  in  processing  speed,  degree 
of  automation,  dependency  on  another  network  element,  and 
processing  parameters.  Also,  for  the  period  1975  through 
1978  the  net  change  in  AUTODIN  I  medium  speed  (600-1200 
baud)  and  high  speed  (2400-4800  baud)  terminals  has  been  an 
increase  of  64  with  a  corresponding  decrease  of  61  in  low 
speed  (300  baud  and  below)  terminals.  Over  the  same  time 
period,  a  total  of  96  Mode  V  (75  baud)  AUTODIN  I  terminals 
have  been  eliminated,  with  an  increase  of  85  Mode  II  terminals. 

2.  Analysis  of  these  terminal  character¬ 
istics  will  continue  in  order  to  provide  the  necessary 
information  to  prepare  common  foully  of  terminals  functional 
specifications. 

5.  Security.  -  ’ 


a.  Definition.  The  development  of  an  architecture 
for  the  mid-term  IAS  requires  that  many  technical,  engineering, 


functional  and  policy  factors  be  investigated.  One  of  the 
major  issues  to  be  investigated  is  that  of  effectively 
satisfying  security  requirements.  The  evolving  IAS  imposes 
new  and  challenging  demands  on  system  design  in  the  area  of 
security  and  access  control.  As  the  AUTODIN  II  system 
evolves  into  the  IAS  and  the  current  AUTODIN  I  is  phased 
out,  the  IAS  will  be  increasingly  required  to  support  a  wide 
mix  of  user  communities  and  to  provide  a  variety  of  network 
services,  many  of  which  are  not  available  in  the  present 
AUTODIN  system.  This  integrated  collection  of  users  and 
services  will  require  the  network  security  functions  to 
share  the  responsibility  for  maintaining  user  community 
separation,  controlling  user  access  to  network  services, 
controlling  network  access  to  community  resources,  and 
ensuring  the  overall  integrity  and  protection  of  subscribers 
from  hostile  external  elements.  Meeting  these  responsibilities 
requires  that  multi-level  computer  security  disciplines  and 
advanced  COMSEC  techniques  be  employed  as  appropriate. 

Security  measures  have  historically  been  added  to  a  system 
after  the  basic  system  design  is  done.  This  practice  often 
results  in  a  less  than  optimal  security  architecture  and 
degradation  of  overall  system  performance.  To  prevent  this 
from  occurring  in  the  mid-term  IAS,  security  is  being  included 
as  a  major  factor  in  early  system  planning,  architecture 
development  and  system  design. 

b.  Requirements.  The  initial  phase  of  AUTODIN  II 
will  provide  the  same  security  services  and  capabilities 
as  dnps  the  current  AUTODIN  I  system.  AUTODIN  II 
will  employ  the  same  conventional  COMSEC  but  will  incor¬ 
porate  muitx- level  security  techniques,  which  will  provide 
user  authentication  and  security  kernel  segregation  of 
classified  traffic.  As  the  IAS  begins  to  evolve  from  AUTODIN 
II  into  a  mature,  fully  integrated  backbone  network  providing 
a  variety  of  network  services  to  a  wide  mix  of  user  communities, 
it  is  unlikely  that  the  conventional  COMSEC  techniques  will 
be  sufficiently  sophisticated  or  cost-effective  for  the  en¬ 
cryption.  Controlling  access,  maintaining  user  separation, 
and  protecting  user  information  within  the  IAS  will  be 
handled  by  the  multi-level  security  techniques.  Thus,  the 
mi*j-term  IAS  should  include  the  upgrading  of  security  services 
and  capabilities,  as  an  integral  part  of  the  overall  system 
evolution,  through  the  application  of  advanced  COMSEC  and  by 
applying  multi-level  security  techniques  to  all  elements  of 
the  IAS  architecture.  The  IAS  security  subsystem  should 
satisfy  three  basic  requirements:  (1)  provide  a  transparent 
secure  switching/transmission  system  for  subscribers  using 
the  IAS  as  a  basic  communications  backbone;  (2)  provide 
subscriber8  secure  special  network  services;  and  (3)  provide 
reliable  security  services  with  minimum  system  life  cycle 
costs.  J 
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(1)  The  first  requirement  responds  to  the 
policy  that  the  IAS  will  be  the  single  major  data  communica¬ 
tions  network  for  DoD.  If  this  IAS  program  objective  is  to 
be  achieved,  then  special  user  communities  (e.g.,  WWMCCS, 
SACDIN,  DODIIS,  etc.)  should  be  able  to  use  the  IAS  as  a 
basic  communications  backbone  with  the  confidence  that  their 
security  requirements  are  maintained  by  the  shared  IAS 
network  as  effectively  as  they  would  be  by  a  private,  dedicated 
network. 

(2)  The  second  requirement  responds  to  the 
philosophy  that  IAS  will  provide  subscribers  with  special 
network  features  and  services,  beyond  message/data  trans¬ 
mission  and  switching,  such  as  automated 

message  processing,  informal  message  exchange,  data  telecon¬ 
ferencing,  etc.  If  these  network  provided  services  are  to 
be  of  real  value  to  a  subscriber,  they  must  incorporate  the 
necessary  safeguards  to  insure  user  privacy  and  permit  the 
processing  of  classified  user  information. 

(3)  The  third  security  requirement  is  to  provide 
users  with  end-to-end  security  protection  through  the  inte¬ 
grated  application  of  conventional  and  advanced  COMSEC  tech¬ 
niques  and  computer  multilevel  security  techniques. 

(a)  End-to-End  Security.  In  the  IAS,  end- 
to-end  security  simply  means  that  a  subscriber's  information 
is  provided  a  secure  virtual  path  from  its  source  through 
the  network  to  its  destination.  This  secure  virtual  path 
protects  the  subscriber's  information  from  unauthorized 
access,  disclosure,  modification,  or  destruction.  The  path 
is  created  in  different  ways  depending  upon  a  user's  needs 
and  capabilities.  For  example,  one  class  of  users  with 
highly  sensitive  data  will  be  provided  a  secure  path  through 
the  network  using  end-to-end  encryption  (E3)  techniques. 

The  E3  users  will  be  fully  protected  using  a  single  encryption/ 
decryption  process  between  source  and  destination. 

(b)  Link  Encryption.  Another  class  of 
users  will  rely  on  the  conventional  AUTODIN  I/II  link  encryp¬ 
tion  approach  for  end-to-end  security  through  the  network. 

These  non-E3  users  will  undergo  multiple  encryption/  decryption 
processes  between  source  and  destination.  Although  their 

data  will  appear  unencrypted  within  intermediate  Nodes,  the 
integrity  of  their  end-to-end  secure  patch  will  be  main¬ 
tained  by  employing  computer  multilevel  security  techniques, 
physical  security,  and  personnel  security  at  the  PSNs  to 
protect  the  unencrypted  data. 


(c)  Computer  Multilevel  Security  (MLS). 

The  MLS  techniques  will  also  be  a  major  factor  in  providing 
complete  end-to-end  security  to  both  E3  and  non-E3  users 
when  accessing  network  service  processors.  The  network  will 
provide  secure  paths  to  these  service  processors.  Once  the 
service  processor  is  accessed,  then  MLS  techniques  will 
permit  users  with  various  security  requirements  to  simultan¬ 
eously  obtain  service  from  a  common  processor.  The  mix  of 
security  levels  permitted  within  a  network  service  processor 
will  depend  on  the  ability  to  certify  and  accredit  MLS 
hardware  and  software  for  these  processors.  However,  it  is 
envisioned  that  the  mature  IAS  will  eventually  offer  network 
services  from  a  common  machine  to  users  with  security  require¬ 
ments  ranging  from  unclassified  through  Top  Secret  and 
Special  Intelligence.  In  addition,  subscribers  may  apply 
MLS  techniques  within  their  own  host  processors  to  achieve  a 
similar  capability  to  share  those  resources  among  users  with 
differing  security  requirements. 

6.  New  Elements.  As  part  of  the  architecture  definition 
process,  the  following  network  elements  could  be  developed 
and  implemented  in  the  mid-term: 

a.  Central  Service  Facility  (CSF) .  The  CSF  is  a 
postulated  new  centralized  network  service  element  that 
would  perform  necessary  user  support  functions  and/or  network 
functions  to  accomplish  message  delivery  and  provide  needed 
user  services.  The  CSF  is  accessed  via  the  backbone  network 
and  does  not  directly  terminate  subscriber  equipments.  The 
CSF  would  connect  to  the  network  via  the  PSNs  through  an 
AUTODIN  II  host  computer  interface.  The  specific  functional 
capability  of  the  CSF  is  dependent  upon  the  architectural 
alternative  selected. 

b.  Inter-Service/Agency  AMPE  Enhanced  (Phase  II). 

This  new  element  is  postulated  as  a  network  service  element 
that  can  be  derived  from  installed  I- S/A  AMPEs  through 
modular  expansion  of  software  (and  if  necessary  hardware) . 

The  I-S/A  AMPE(E)  would,  therefore,  include  all  of  the 
functions  of  an  I-S/A  AMPE  as  described  above  and  replace  a 
normal  I-S/A  AMPE  in  the  network  at  selected  locations.  In 
addition,  the  enhanced  I-S/A  AMPEs  would  provide  the  additional 
network  functions  needed  to  allow  phase  out  of  existing  ASCs 
and  provide  new  functions  allocated  by  the  architecture. 

The  I- S/A  AMPE(E)  would  terminate  both  narrative/record  and 
computer  data  oriented  users  and  connect  to  the  network  via 


an  AUTODIN  II,  host  computer  interface.  The  functional 
capability  of  the  I-S/A  AMPE(E)  depends  on  the  architecture 
alternative. 


c.  Common  Family  of  AUTODIN  Terminals.  A  new 
family  of  terminal  equipments  is  being  defined  as  part  of 
the  IASA  project.  This  common  family  will  include  a  full 
range  of  terminals  from  simple  teletypewriter  to  automated 
user  terminals.  The  functional  capabilities  of  these  terminals 
will  be  defined  on  the  basis  of  user  requirements  and  are 
independent  of  the  architectural  alternatives  selected. 

7.  Functional  Requirements .  The  mid-term  IAS  will 
provide  many  of  the  telecommunications  capabilities  which 
exist  within  the  current  state-of-the-art  but  are  not  now 
fully  exploited.  The  IASA  Part  I  report  discussed  a  number 
of  these  telecommunications  capabilities  as  part  of  the  IAS 
architecture  definition  process,  such  as  teleconferencing, 
word  processing,  internetting  of  data  bases  and  networks,  and 
facsimile.  These  capabilities  will  include  the  basic  narrative/ 
record  services  currently  provided  by  the  AUTODIN  I  system,  the 
new  computer  oriented  services  defined  for  the  AUTODIN  II  system, 
and  several  new  data  services.  During  the  IAS  architecture 
definition  process  a  number  of  basic  functional  requirements 
were  identified  and  defined.  It  is  anticipated  that  addi¬ 
tional  requirements  will  be  defined  throughout  the  near-term 
based  on  user  experience  with  the  AUTODIN  II  system  and 
evolving  data  needs.  The  mid-term  functional  requirements 
are  organized  into  the  following  seven  categories  of  service: 

a.  Narrative /Record  Message  Transfer.  This  service 
includes  the  secure  user-to-user  transfer  of  message  traffic 
provided  by  the  current  AUTODIN  I  System.  Using  this  service 
any  user  in  the  system  (equipped  with  appropriate  terminal 
equipment)  may  transmit  narrative/record  traffic  to  one  or 
more  other  users.  The  major  service  features  provided  by 
the  network  are  message  accountability  and  retrieval,  multiple/ 
collective  address  routing,  and  code  and  format  conversions. 

This  service  will  be  available  to  all  IAS  subscribers  in 
some  form. 

'  b.  Narrative/Record  Message  File  Retrieval.  This 

service  provides  storage  of  message  traffic  on-line  for 
retrieval  upon  request  from  users.  Narrative/record  messages 
passing  through  the  network  are  automatically  stored  for  a 
prescribed  period  of  time.  Other  data  such  as  standard 
forms  may  be  also  stored  by  a  user  for  later  recall.  The 
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nodal  elements  which  contain  the  message  files  perform  the 
processing  to  store  messages,  control  access  to  the  files 
and  remove  messages  from  the  file  at  user  direction  or  time 
expiration.  The  service  is  presently  provided  in  various 
forms  by  some  AMPEs  in  the  current  AUTODIN  I  system,  and 
should  be  provided  to  all  narrative/record  subscribers  of 
the  IAS. 

c.  ADP  Transaction  Transfer.  This  service  provides 
secure  interactive,  query/response  and  bulk  data  tiansfer  as 
presently  defined  for  the  AUTODIN  II  network.  No  message 
processing  functions  or  accountability  are  provided  by  the 
network.  Traffic  entered  into  the  network  contains  segment 
leader  information  and  is  routed  through  the  network  on  a 
packet  basis.  Only  packet  or  segment  intransit  storage  is 
provided.  This  service  should  be  available  to  computer 
oriented  IAS  subscribers. 

d.  Privacy  Service.  This  service  is  equivalent  to 
the  present  AUTODIN  I  Limited  Privacy  Service.  The  traffic 
is  handled  as  normal  narrative/record  traffic  except  that  no 
permanent  history  or  retrieval  storage  is  retained  in  the 
system.  The  service  should  be  available  to  narrative/record 
subscribers.  (This  type  of  privacy  is  inherent  for  ADP 
transactions  since  no  record  of  that  traffic  is  retained  in 
the  system. ) 

e.  Informal  Message  Exchange.  This  service  allows 
for  the  exchange  of  informal  or  unofficial  information  among 
users.  It  is  similar  to  narrative/record  message  transfer 
except  limited  network  functions  are  provided.  An  abbreviated, 
simplified  format  is  used  and,  therefore,  no  format  conversion 
is  provided.  Message  storage  and  retrieval  functions  are 

not  provided,  i.e.,  only  intransit  storage  is  provided.  The 
service  should  be  available  to  all  IAS  subscribers. 

f.  Mailbox  Service.  This  service  allows  a  user  to 
send  messages  to  a  storage  location  in  the  network  for 
subsequent  retrieval  by  the  addressee.  Mailbox  service  is 
an  augmentation  to  the  informal  message  exchange  service. 

g.  Data  Teleconferencing.  This  service  allows  a 
conference  to  be  conducted  among  network  subscribers  using 
teletypewriters,  video  display  terminals,  or  similar  terminal 
devices.  Conferencing  may  be  simultaneous  (conference 
members  exchange  transactions  on  a  real-time  basis)  or 
delayed  (members  enter  and  retrieve  transactions  at  their 
own  convenience).  A  transaction  may  be  addressed  to  the 
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conference  or  to  any  member  of  the  conference.  A  network 
element  will  control  the  conference,  store  conference  trans¬ 
actions  and  respond  to  requests  for  conference  data  or 
status  information  from  the  members.  The  data  teleconference 
service  is  an  augmentation  of  the  informal  message  exchange 
service  and  should  be  available  to  most  subscribers. 

D.  Special  Items.  The  purpose  of  this  sub-section  is  to 
provide  the  status  of  several  key  action  items  that  are  an 
influencing  factor  in  the  evolving  mid-term  architecture. 

1 •  Telecommunications  Center  Consolidation  and  Exten¬ 
sion  of  Automation  Program. 


a.  Background.  A  major  DoD  objective  is  the  con¬ 
solidation  of  telecommunications  centers  (TCC)  and  other 
message  processing  facilities  to  the  maximum  extent  consistent 
with  cost  benefits,  survivability  and  responsive  service  to 
the  user.  The  major  consolidation  program  benefit  is  the 
potential  savings  through  decreased  operating,  maintenance 
and  personnel  costs.  Such  savings  are  achieved  through 
physical  consolidation  of  TCCs,  either  through  integration 
or  collocation,  or  through  extension  of  automation  from  an 
AMPE.  Physical  consolidation  involves  closing  a  TCC  and 
providing  over-the-counter  service  from  a  remaining  TCC.  In 
this  case,  a  single  integrated  facility  may  provide  service 
or  facilities  may  be  collocated  within  the  same  building 
area.  Extension  of  automation  involves  connection  as  a 
remote  terminal  to  an  AMPE.  The  remote  terminal  uses  the 
automated  capabilities  of  the  AMPE  to  perform  the  message 
processing  functions  which  would  normally  be  done  manually 
if  the  terminal  were  to  be  directly  connected  to  the  AUTODIN 
system.  TCC  consolidation  and  extension  of  automation 

de9reases  *-n  the  number  of  directly  connected 
AUTODIN  terminals.  Extension  of  automation  results  in  an 

d®?and  for  the  I-S/A  AMPE,  and  promotes  a  distributed 
AUTODIN  architecture.  The  following  paragraphs  summarize 
consolidation  and  extension  of  automation  progress  within 
the  DoD  community. 

D  p^fysical  Consolidation.  As  stated  in  the  IASA 

the  DoD  telecommunications  community  had 
identified  140  locetions  offering  sufficient  potential  for 
ice  consolidation  as  to  warrant  a  detailed  feasibility 
study.  To  date,  66  consolidations  have  been  approved  or 
completed,  26  consolidations  are  not  feasibile,  and  studies 
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for  the  remaining  48  locations  are  in  process.  Almost  all 
the  140  locations  involve  consolidation  of  a  TCC  processing 
General  Service  (GENSER)  traffic  with  a  TCC  processing 
Defense  Special  Security  Communications  System  (DSSCS) 
traffic.  In  general,  those  actions  found  feasible  require 
closing  of  the  DSSCS  TCC,  with  over-the-counter  service 
provided  from  the  GENSER  TCC.  Although  such  actions  usually 
reduce  the  total  number  of  TCC  personnel  required,  the  total 
number  of  personnel  needing  access  to  Sensitive  Compartmented 
Information  (SCI)  is  generally  increased.  The  Director, 
Central  Intelligence,  however,  placed  a  moratorium  on  new 
SCI  billets  in  June  1977.  As  a  result,  ASD/C^I  requested  a 
waiver  to  the  moratorium  to  allow  continuation  of  new  programs 
through  December  1979,  and  has  recently  received  approval  to 
permit  the  TCC  R/Y  consolidation  program  to  proceed. 

c.  Extension  of  Automation.  JCS  Memorandum  of  Policy 
165  limits  extension  of  automation  by  restricting  the  distance 
between  a  remote  terminal  and  its  servicing  AMPE  to  25  miles. 
Any  proposed  connection  exceeding  the  25  mile  limitation  must 
be  coordinated  with  DCA  and  approved  by  OJCS  on  a  case-by-case 
basis.  This  procedure  is  a  safeguard  against  establishment 
of  dedicated  networks  vice  use  of  the  common  user  networks. 

In  the  short  term  it  restricts  extension  of  automation  with 
fielding  of  the  I-S/A  AMPEs,  the  distance  limitation  of  25 
miles  will  be  reassessed  as  DCA  has  overall  program  manage¬ 
ment  control. 

(1)  In  a  effort  to  ensure  the  individual 
Service/ Agency  programs  were  not  providing  redundant  AMPE 
systems  serving  a  single  geographic  location,  OJCS  initiated 
two  actions.  The  first  tasked  CINCPAC  and  CINCEUR  to  review 
geographic  areas  of  responsibility.  These  reviews  have  been 
completed.  CINCEUR  determined  no  unnecessary  AMPE  installa¬ 
tions  were  installed  or  planned  CINCPAC  arrived  at  the 
same  conclusion,  with  one  exception  -  the  CINCPAC  review 
recommended  a  study  of  the  feasibility  of  consolidating 
Makalapa  and  Camp  Smith  LDMX  installations  on  Oahu.  OJCS 
subsequently  tasked  CINCPAC  to  conduct  the  recommended 
study,  which  is  now  underway.  A  consolidated  system  on  Oahu 
is  viewed  as  a  potential  candidate  for  installation  of  the 
I-S/A  AMPE. 


(2)  The  second  OJCS  initiative  is  in  process. 
It  involves  approximately  25  locations  within  the  CONUS, 
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each  of  which  is  assigned  to  a  Service/Agency,  generally 
with  the  greatest  local  interest.  Services /Agencies  will 
study  the  feasibility  of  extending  automation  from  a  local 
AMPE  to  all  DoD  TCCs  within  the  local  area.  Completion  of 
all  studies  is  anticipated  by  January  1980.  The  results 
will  be  factored  into  the  I-S/A  AMPE  acquisition  program. 

-  d.  DSSCS/GENSER  Accreditation.  In  January  1978, 
ASD/CJI  released  a  manual  providing  security  criteria  and 
telecommunications  guidance  for  the  protection  of  Special 
Intelligence  stored  and/or  processed  in  a  consolidated 
DSSCS/GENSER  Automated  Message  Processing  System.  Prior  to 
its  use  for  DSSCS  traffic,  any  automated  system,  such  as  the 
AMPE,  must  be  accredited  by  NSA  or  DIA,  as  appropriate.  The 
manual  governs  automated  systems  without  connected  remote 
terminals,  those  with  only  DSSCS  connected  remote  terminals, 
and  those  with  one  or  more  GENSER-only  remote  terminals. 

The  intensity  of  the  security  risk  is  greatest  for  systems 
with  GENSER-only  connected  remote  terminals.  Accordingly, 
the  criteria  are  applied  most  rigorously  to  such  cases. 

(1)  Within  the  separate  Service/Agency  AMPE 
programs,  only  the  NSA  STREAMLINER  has  been  granted  DSSCS 
accreditation.  The  STREAMLINER  has  not,  however,  been 
accredited  to  accept  both  DSSCS  and  GENSER  remote  terminals. 
The  results  of  an  NSA  feasibility  study  indicate  such  accredi 
tation  would  not  be  cost  effective.  Navy  is  attempting  to 
obtain  DSSCS/  GENSER  certification  for  its  London  LDMX 
facility;  however,  accreditation  for  GENSER-only  remote 
terminals  will  only  be  sought  after  successful  accreditation 
in  a  "system-high"  environment.  At  this  time,  Navy  does  not 
plan  to  seek  accreditation  for  the  NAVCOMPARS  AMPE.  Air 
Force  and  Army  are  coordinating  with  NSA  to  obtain  accredita¬ 
tion  for,  respectively,  the  AFAMPE  and  AMME  systems. 

(2)  It  is  essential  that  the  I-S/A  AMPE  be 
accredited  to  service  simultaneously  both  DSSCS  and  GENSER 
remote  terminals;  otherwise,  local  geographic  areas  will 
continue  to  require  separate  DSSCS  and  GENSER  AMPE  facilities 
Accordingly,  development  of  the  I-S/A  AMPE  will  be  conducted 
in  close  coordination  with  NSA,  to  ensure  the  system  archi¬ 
tecture  is  compatible  with  DSSCS/GENSER  accreditation. 

2.  Automated  Message  Handling  Systems  (AMHS) .  This 
section  provides  a  brief  summary  of  AMHS  program  background, 
and  contains  an  assessment  of  DoD  AMHS  program  direction  and 
its  potential  impact  to  the  IASA  project. 
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a.  AMHS  Definition.  Automated  Message  Handling 
Systems  (AMHS)  are  computer  based  systems  consisting  of  one 

or  more  processors  and  associated  terminals  which  collectively 
automate  the  receipt,  distribution,  storage,  retrieval, 
preparation,  review,  or  transmission  of  narrative  pattern 
message  traffic.  They  are  typically  used  to  automate  communi¬ 
cations  center  functions  as  well  as  end  user  message  handling 
tasks,  particularly  in  the  high  volume  environments  associated 
with  command  and  intelligence  watch  centers.  The  definition 
excludes  data  processing  systems  that  receive  messages  as 
part  of  the  data  base  updating  process.  The  term,  in  particular, 
includes  such  automated  telecommunications  oriented  systems  as 
the  Automated  Message  Processing  Exchange  (AMPE) ,  command  and 
control  oriented  systems  such  as  the  National  Military 
Command  Center  (NMCC)  Information  and  Display  System  (NIDS) , 
and  intelligence  oriented  systems  such  as  the  National 
Military  Intelligence  Center  Support  Subsystem  (NMIC-SS) . 

The  telecommunications  oriented  systems  primarily  aid  the 
communicator,  i.e.,  they  automate  tasks  which  would  otherwise 
be  accomplished  manually  by  communications  personnel.  The 
command  and  control  and  intelligence  systems  are  categorized 
as  user  oriented  systems,  i.e.,  they  primarily  aid  the 
writer/reader  by  automating  tasks  associated,  e.g.,  with 
message  composition,  data  base  search,  etc.  Such  systems 
would  typically  be  used  by  intelligence  center  analysts  and 
command  center  personnel. 

b.  Background. 

(1)  On  25  March  1977,  the  Surveys  and  Investi¬ 
gations  Staff  of  the  House  Appropriations  Committee  (HAC) 
published  a  report  highly  critical  of  DoD  management  in  the 
development  of  AMHS,  citing  lack  of  standardization  and 
duplication  of  effort.  The  subsequent  HAC  report  to  the 
House  on  the  FY  1978  DoD  Appropriations  Bill  recommended 
cuts  in  several  AMHS  programs,  and  levied  the  following 
criticisms/comments : 

(a)  There  were  thirteen,  possibly  more, 
different  AMHS  systems  under  development. 

(b)  There  appeared  to  be  unnecessary 
duplication  in  their  development. 

(c)  AMHS  were  not  always  needed  or  designed 
to  meet  the  real  needs  of  the  commander. 


(d)  Users  were  not  given  a  hand  in  system 
development,  and  consequently  did  not  fully  understand  or 
use  the  developed  system. 

(e)  Future  DoD  budget  requests  must  include 
provisions  for  commonality  and  interservice  use  of  hardware 
and  software. 

(2)  In  mid  November  1977,  ASD/C3I  tasked  DCA  to 
lead  a  Service /Agency  review  assessing  the  HAC  criticisms 
and  recommending  an  overall  DoD  AMHS  program  direction.  The 
subsequent  report  was  forwarded  through  OJCS  to  ASD/C3I  in 
January  1978.  It  concluded  that: 

(a)  Functional  standardization  and  opera¬ 
tional  validation  of  telecommunications  oriented  AMHS  are 
being  adequately  addressed  within  the  IASA  project. 

(b)  Functional  standardization  and  opera¬ 
tional  validation  of  the  command  and  control  and  intelligence 
information  oriented  AMHS  are  not  being  comprehensively 
addressed  within  the  DoD,  althrough  those  issues  are  being 
addressed  with  various  degrees  of  success  within  the  individual 
communities  of  interest. 

(3)  In  mid  February  1978,  ASD/C3I  stated  an 
intention  to  prepare  a  comprehensive  AMHS  master  plan.  To 
assist  in  plan  preparation,  DCA,  DIA,  and  OJCS/WSEO  were 
tasked  to  submit,  respectively,  reports  on  the  telecommunica¬ 
tions  AMHS,  the  intelligence  oriented  user  AMHS,  and  the 
command  and  control  oriented  user  AMHS.  Each  report  was  to 
contain  an  assessment  of  AMHS  operational  reports,  in  toto, 
were  to  constitute  an  input  to  the  comprehensive  plan  for 
AMHS  development  and  life  cycle  support. 

(4)  The  AMHS  plan  was  formally  published  on  1 
February  1979.  It  is  comprehensive,  identifying  both  near 
and  far  term  actions,  and  it  tasks  DCA  with  the  discharge  of 
significant  new  AMHS  responsibilities.  The  plan  serves  as 
the  vehicle  whereby  Services /Agencies  are  informed  of  the 
DoD  plan,  Services /Agencies  are  tasked  to  implement  the 
plan,  and  a  rational  and  systematic  AMHS  management  approach 
is  delineated.  The  specific  taBkings  to  DCA  include: 

(a)  Exercise  of  end-to-end  architectural 
management  responsibility  for  both  telecommunications  and 


user  oriented  AMHS.  The  IASA  project  is  recognized  as 
meeting  this  need  for  the  telecommunications  oriented  AMHS. 

(b)  Coordination  of  DoD  AMHS  research  and 
development  activities. 


program. 


(c)  Development  of  the  IASA  and  I-S/A  AMPE 


(d)  Formation  of  a  joint  DCA/DIA  program 
office  for  the  near-term  implementation,  configuration 
control,  and  software  support  of  a  NMICSS  derivation  system 
for  the  AMH  portion  of  the  NIDS. 


(e)  Assumption  of  management  responsibility 
for  system  development  and  life  cycle  support  of  interservice 
common,  fixed  base  AMHS. 


(f)  Development  of  a  compact  version  of 
NMIC-SS  and  its  implementation  to  meet  validated  WWMCCS 
requirements . 


(g)  Development  and  coordination  of  a  near 
term  plan  for  implementation  and  support  of  the  standard 
user-oriented  AMH  system,  and  a  long-range  architectural 
plan  for  the  evolution  of  AMH  systems  in  general.  These 
plans  are  to  be  submitted  to  OSD  for  approval  by  30  September 
1979  and  31  July  1981,  respectively. 

(h)  Submittal,  within  sixty  days  of  AMHS 
plan  publication,  detailed  resource  alternatives  for  the  DCA 
assumption  of  these  AMHS  management  responsibilities. 

(5)  DCA  is  now  developing  the  detailed  resource 
alternatives  mentioned  above,  with  input  to  ASD/C3I  by  April 
1979. 


c.  Program  Direction.  The  goals  and  objectives 
delineated  in  the  AMHS  plan,  when  taken  in  conjunction  with 
the  set  of  specifically  assigned  tasks,  constitute  a  baseline 
for  the  following  projection  of  an  "ideal"  (i.e.,  meeting 
the  stated  objectives)  standard  AMHS  configuration  for  the 
mid  to  late  1980s.  At  the  base,  post,  camp,  station  or 
activity  level,  AMHS  would  be  integrated  into  a  single 
highly  modular  consolidated  facility.  This  would  include 
command  and  control,  intelligence,  and  telcomxnunications 
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AMHS,  each  of  which  might  be  viewed  as  constituting  a  major 
subsystem.  This  system  would  be  capable  of  multilevel 
secure  operation  with  all  applications  software  programmed 
in  a  common  high  order  language.  Further,  the  system  would 
be  able  to  terminate  special  circuits  and  be  able  to  interface 
with  ADP  systems,  including  the  WWMCCS  Information  System 
and  DoD  Intelligence  Information  System  processors.  The 
system  would  be  fielded  in  the  mid-1980s.  Functional  identity 
of  the  three  subsystems  would  ideally,  but  not  necessarily, 
consist  of  the  same  hardware.  The  intelligence  and  command 
and  control  AMHS  subsystems  would  use  a  single  standard 
system.  The  user  AMHS  standard  system  would  also  satisfy 
the  AMHS  requirements  of  other  functional  communities.  Any 
one  of  a  number  of  local  architectural  arrangements  could 
meet  the  objectives.  One  such  local  architecture  would 
consist  of  three  mini-computer  clusters,  each  serving  a 
functional  community  and  integrated  by  some  mechanism,  such 
as  a  common  bus. 

d.  Impact  to  the  IASA  Project.  The  plan  considers 
the  IASA  project  to  be  the  vehicle  whereby  telecommunications 
AMHS  objectives  are  achieved.  In  this  regard,  current  IASA 
planning  is  viewed  as  a  sound  evolutionary  approach.  Accord¬ 
ingly,  the  impact  to  the  IASA  project  in  the  near-term 
should  be  negligible.  In  the  mid  and  far- term,  the  impact 
may  be  substantial,  in  at  least  two  ways. 

(1)  The  AMHS  plan  envisions  an  AMHS  architecture 
on  an  end-to-end  basis,  i.e.,  terminal- to -user  AMHS  to- 
telecommunications  AMHS-to-network- to  telecommunications 
AMHS,  etc,  as  a  continuum.  It  will  be  necessary  to  analyze 
the  end-to-end  system  architecture  to  determine  where  functions 
should  be  allocated.  For  example,  both  telecommunications 

and  user  AMHS  generally  possess  "delivery  determination" 
software.  Where  such  systems  are  collocated,  it  may  be 
possible  to  achieve  operational  and  economic  efficiencies  by 
providing  the  function  from  a  single  subsystem.  Previously, 
the  user  and  telecommunications  AMHS  have  been  designed  as 
stand-alone  systems,  with  an  interconnecting  communications 
interface. 

(2)  The  second  potential  area  of  impact  to  the 
IASA  project  relates  to  user  AMHS  functions.  The  plan  tasks 
DCA  to  address  inclusion  of  certain  user  AMHS  functions, 
meeting  the  needs  of  functional  communities  other  than 
command  and  control  and  intelligence,  within  the  IASA  project. 


The  I-S/A  AMPE  program  development  should  provide  sufficient 
flexibility  to  assure  eventual  introduction  of  user  AMHS 
modules  where  required. 

3.  ARPANET  Connectivity  to  AUTODIN  II. 

a.  General.  The  ARPANET  connectivity  to  AUTODIN  II 
was  a  special  item  in  the  previous  IASA  Report,  and  the 
subject  is  herein  updated  to  reflect  current  status.  The 
ARPANET  provides  operational,  common  user,  data  communications 
service,  and  is  also  used  for  packet  switching  R&D  to  demonstrate 
advances  in  data  communications  technology.  DARPA  and  DCEC 

have  stated  a  continuing  R&D  requirement  through  mid  to  late 
1980s.  There  is  also  a  User-Server  Intercommunications  require¬ 
ment  among  all  of  its  users,  including  military  users,  non 
military  users  and  servers  and  particularly  to  DARPA  sponsored 
servers  at  universities  and  corporations.  The  connectivity  to 
AUTODIN  II  should  provide  continuing  intercommunication  for 
these  users. 

b.  Alternatives.  Four  alternatives  have  been  identi¬ 
fied  for  the  ARPANET  users  to  connect  to  AUTODIN  II.  In 
summary,  they  are: 

(1)  Alternative  I.  Continue  ARPANET  operation; 
qualified  users  selected  to  transition  to  AUTODIN  II. 

(2)  Alternative  II.  All  non  R&D  DoD  users  transition 
to  AUTODIN  II,  with  residual  ARPANET  for  R&D  users;  require 
security  certifiable  gateway  between  networks.  There  are  three 
options  in  this  alternative,  involving  different  network 
front-ends,  software  and  costs. 

Option  1.  Hosts  transferring  to  AUTODIN  II 
would  reprogram  their  front-ends 
to  meet  AUTODIN  II  protocols. 

Option  2.  Hosts  would  use  modified  MCCU 
programmed  to  accept  ARPANET 
messages  and  translate  addresses 
,  to  AUTODIN  II  logical  addresses. 

Option  3.  Non  R&D  ARPANET  nodes  would  be 
reprogrammed  with  SIP  protocols ; 
the  nodes  would  effectively  act 
as  host/terminal  concentrators. 


(3)  Alternative  III.  Use  of  a  Value  Added  Net¬ 
work  (VAN)  for  both  R&D  and  non  R&D  users. 

(4)  Alternative  IV.  Use  of  a  VAN  for  non  R&D 
users,  while  maintaining  residual  R&D  ARPANET. 

c.  Analysis. 

(1)  Alternative  I  maintains  status  quo  for  R&D 
users,  preserves  user- server  relationships,  and  is  the 
lowest  cost  alternative.  Although  Honeywell  based  equipment 
is  no  longer  supported  by  the  vendor,  adequate  maintenance 
from  current  contractor  is  expected  for  at  least  five  years. 
Expansion  of  the  network  is  limited  by  available  equipment 
alternatives . 


(2)  Alternative  II  has  the  3  options  which 
partially  satisfy  the  OSD  intent  that  DoD  ADP  system  users 
transition  to  AUTODIN  II,  but  would  require  a  change  to 
current  AUTODIN  access  policy  to  permit  non- DoD/non- Government 
user  access.  Options  1  and  3  have  major  impact  on  host  soft¬ 
ware.  This  alternative  also  has  the  highest  transition  costs 
of  all  alternatives. 

(3)  Alternative  III  uses  a  VAN  with  gateways, 

and  represents  the  next  to  lowest  cost  of  the  three  alternatives. 
It  has  an  earlier  implementation  period  than  the  Alternative 
II  opt'ons,  1980  versus  1982,  but  it  will  not  support  the 
oversea  ARPANET  requirements.  It  is  the  only  option  in 
which  ARPANET  nodes  are  completely  removed. 

(4)  Alternative  IV  uses  both  a  VAN  and  a  gateway 
to  the  residual  R&D  ARPANET.  It  has  the  same  implementation 
period  as  Alternative  III,  but  has  higher  transition  costs 
than  Alternatives  I  and  III.  Similar  to  Alternative  III,  it 
does  not  satisfy  the  OSD  intent  to  transition  DoD  ARPANET 
users  to  AUTODIN  II. 

d.  Approach.  DCA  should  continue  to  operate  the 
ARPANET  under  the  Alternative  I  approach,  with  qualified 
military  users  transferred  to  AUTODIN  II  in  1981.  DCA  and 
DARPA  should  continue  the  development  of  gateways  between 
the  ARPANET  and  the  AUTODIN  II.  DARPA  estimates  that  these 
gateways  should  be  available  by  1981.  When  both  the  AUTODIN 
II  and  the  gateways  are  operational,  DCA  and  ARPANET  sponsors 
should  identify  the  most  cost  effective  network  connectivity 
to  satisfy  existing  and  future  requirements. 
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4.  Billing  Structure. 


a.  The  Assistant  Secretary  of  Defense  (Comptroller) 
has  approved  continuation  of  the  present  method  of  billing 
AUTODIN  customers  through  FY  1980.  This  is  a  single  sub¬ 
scriber  rate  schedule  for  all  categories  of  service  offered 
by  the  AUTODIN  network  and  is  based  on  connectivity  and  the 
baud  rate  of  the  access  lines.  Subscriber  rates  are  published 
semi-annually  by  the  DCA  Comptroller's  office. 

b.  The  monthly  backbone  rate  charged  AUTODIN  customers 
is  used  to  pay  for  the  cost  of  AUTODIN  leased  switches, 
operation  and  maintenance  of  switching  centers ,  interswitch 
trunks,  interconnects  into  AUTOVON  and  seventy  percent  of 

the  channel  control  units  interface  software. 

c.  For  FY  1981,  DCA  is  studying  the  merits  of 
expanding  the  coverage  of  the  backbone  to  also  include  costs 
associated  with  service  facilities  such  as  AMPEs,  subscriber 
access  lines,  modems,  multiplexers,  concentrators,  interface 
development  to  include  software  design  and  development,  and 
leased  hardware  costs.  In  essence,  consideration  is  being 
given  to  including  all  costs  of  the  system  with  the  exception 
of  equipment  procured  by  the  government  and  terminal  equipment 
funded  by  the  customers. 

5.  Standards .  To  realize  both  economy  and  interopera¬ 
bility,  lASA  design  requires  broad  range  standardization 
where  practicable.  This  standardization  includes  the  communi¬ 
cations  procedures,  protocols,  interfaces,  modes,  formats, 
message  handling,  security  and  privacy,  as  well  as  needed 
staffing  standards  for  AUTODIN  system  elements.  These 
standards  are  needed  to  provide  the  design  criteria,  the 
development  structure,  and  the  implementation  scheme  for  the 
future  AUTODIN  communication  system.  The  LASA  goal  to 
design  and  engineer  a  system  on  a  terminal  to  terminal 
basis,  complete  and  integrated  from  end  to  end,  will  not 
only  reduce  design  inefficiencies  and  implementation  costs, 
but  will  also  enhance  interoperability  with  present  and 
future  systems.  In  response  to  ASD/C3I  tasking,  standards 
in  these  and  other  areas  are  being  identified,  developed, 
ajid  promulgated.  The  following  is  a  summary  of  major 
standardization  efforts: 

a.  DD  Form  173  Standardization. 

(1)  A  study  was  made  of  the  present  DD  Form  173 
Joint  Messageform  and  discovered  that  each  MILDEP  had  made 
deviations  to  the  standard  form  provided  in  MIL-STD-188c. 


The  study  also  revealed  that  each  MILDEP,  and  in  most  cases 
local  requirements,  dictated  the  preparation  of  the  form  to 
meet  local  optical  character  reader  (OCR)  equipment  software 
and  hardware  requirements. 

(2)  To  provide  a  DoD  standard  form  the  three 
forms  were  compared  and  a  revision  developed  to  include 
additional  information  and  new  requirements  such  as  providing 
for  the  Special  Category  designators.  At  the  same  time  a 
standard  procedure  for  the  completion  of  the  form  was  developed. 
The  MCEB  has  approved  the  revised  form  and  instructions  have 
been  promulgated  in  a  printed  change  to  ACP  121.  Distribution 
of  this  change  was  completed  during  January  1979  with  manda¬ 
tory  implementation  of  the  revision  on  1  January  1980. 

b.  Plain  Language  Address  Directory. 

(1)  The  development  of  a  standard  Plain  Language 
Address  Directory  (PLAD)  for  record  telecommunications  has 
been  needed  for  some  time.  With  the  introduction  of  OCRs, 
the  use  of  computers  to  provide  PLA/Routing  Indicator  look¬ 
up,  consolidation  of  telecommunications  centers,  and  the  use 
of  AMPEs,  the  need  for  having  a  standard  unique  identification 
for  a  specific  organization,  DoD-wide,  is  imperative. 

(2)  The  MCEB  in  1976  directed  that  a  Joint  PLAD 
be  developed  to  include  all  DoD  activities  not  listed  in 
Service  publications  and  all  other  activities  that  use  DoD 
communications  facilities.  In  March  1977  a  draft  Joint  DoD 
PLAD  was  distributed  to  Unified  and  Specified  Commands, 

MILDEPs,  and  DoD  Agencies  for  evaluation  and  comments. 

Comments  were  forwarded  to  the  MCEB  to  determine  the  usefulness 
of  the  Joint  PLAD.  Based  on  inputs  received,  the  MCEB 

issued  a  directive  in  September  1978  for  the  development  of 
a  Joint  DoD  PLAD. 

(3)  The  Call  Signs  Panel  of  the  MCEB  is  deter¬ 
mining  the  scope,  format,  content,  update  maintenance,  and 
distribution  of  a  Joint  DoD  PLAD.  Except  for  printing  and 
distribution,  development  of  a  Joint  DoD  PLAD  should  be 
completed  by  July  1979. 

c.  Automated  Message  Distribution  System. 

(1)  For  several  years  the  MCEB  has  been  attempt¬ 
ing  to  develop  a  standard  message  delivery  system.  In  June 
1975,  Ketron,  Inc. ,  studied  the  problem  and  provided  recommended 
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methods  for  an  automated  message  distribution  system.  The 
study  was  reviewed  by  the  MCEB,  and  a  briefing  given  to  the 
Service /Agency  principals  in  June  1976.  It  was  recommended 
that  the  study  be  forwarded  to  the  JCS  for  review  and  comments 
by  Services /Agencies  administrative  staffs.  Subsequently, 

JCS  forwarded  the  Ketron  study  to  the  Services  and  Agencies 
for  comments  and  recommendations.  After  receipt  of  the 
comments  a  joint  action  was  opened  in  April  1977  to  respond 
to  the  MCEB.  JCS  response,  provided  the  MCEB  in  October 
1978,  did  not  agree  with  the  Ketron  study  recommendation  to 
use  a  subject  index  coding  system,  but  rather  recommended 
that  a  standard  should  be  developed  which  capitalizes  on 
automated  message  processing  capabilities  that  will  minimize 
the  burden  on  both  the  message  writer  and  recipient. 

(2)  The  MCEB  has  appointed  DCA  as  lead  agent  to 
develop  a  standard  Automated  Message  Distribution  System. 

Action  on  this  item  should  be  completed  by  October  1979. 

d.  Staffing  Standards. 

(1)  The  automation  of  operational  functions  in 
telecommunications  centers  has  focused  attention  on  the  need 
to  revise  the  present  DoD  staffing  standard  for  manual  and 
semi- automated  telecommunications  centers.  In  December 

1977,  joint  Service /Agency  ad  hoc  working  groups  were  appointed 
under  the  IASA  project  charter,  to  develop  staffing  standards 
for  telecommunications  facilities  (manual/semiautomated 
TCCs ,  ASCs,  and  AMPEs) . 

(2)  The  first  working  group  was  tasked  to 
develop  a  staffing  standard  for  manual  and  semi -automated 
telecommunications  centers.  Their  report  was  submitted  to 
DCA  in  September  1978.  After  review  by  the  IASA  Technical/ 
Policy  Panel  a  draft  DOD  Instruction  was  forwarded  to  ASD/C3I 
in  November  1978  for  approval  and  implementation. 

(3)  The  second  working  group  was  tasked  to 
develop  a  staffing  standard  for  ASCs.  Their  report  is  under 
review  at  DCA  and  a  draft  DoD  Instruction  should  be  forwarded 
to  ASD/C3I  by  June  1979. 

(A)  A  third  working  group  was  tasked  to  develop 
a  staffing  standard  for  AMPEs.  This  group  should  provide  a 
report  to  DCA  by  December  1979. 

e.  Privacy  Considerations. 


In  AUTODIN  I,  the  AUTODIN  Limited  Privacy  System  (ALPS) 
provides  the  required  level  of  privacy  by  not  recording 
traffic  on  history  tapes  within  the  ASC.  AUTODIN  II  will 
also  support  access  restrictions  to  a  community-of- interest 
based  upon  Transmission  Control  Code  (TCC)  designators. 

(1)  TCCs  are  not  intended  to  replace  existing 
ADP  system  controls,  such  as  passwords  or  file  names.  Each 
TCC  is  a  unique  and  separate  code  not  dependent  on  or  related 
to  the  security  classification.  Network  access  requires 
that  all  subscribers  be  assigned  a  TCC.  Any  subscriber  not 
identifying  a  TCC  requirement  will  be  assigned  a  common  user 
network  TCC  and  will  become  a  member  of  the  common  user 
network  community. 

(2)  A  TCC  will  be  identified  in  each  packet  of 
data.  Each  packet  entering  or  leaving  a  packet  switch  by  an 
access  circuit  will  be  validated  as  belonging  to  the  closed 
subscriber  group  having  access  to  that  circuit.  A  TCC  mis- 
macch  (attempted  delivery /connection  to  a  subscriber  not 
authorized  that  TCC)  will  be  handled  the  same  as  a  security 
mismatch.  The  network  will  automatically  generate  a  service 
message  to  the  subscriber  for  an  invalid  TCC  field,  and  a 
report  will  be  made  to  the  packet  switch  operator  and  the 
Network  Control  Center's  (NCC)  controller.  The  NCC  controller 
and  packet  switch  operator  will  follow  procedures  that 
ensure  the  mismatch  is  recorded  and  reported  to  their  security 
representative.  Release  of  TCC  designators  will  be  limited 

to  the  subscriber  group  to  whom  the  TCCs  are  assigned. 

f.  High  Order  Language.  While  the  design  goal  of 
maintaining  flexibility  means  that  software  cannot  be  completely 
standardized,  some  standardization  can  be  provided  through  a 
high  level,  machine  independent,  telecommunications  oriented 
computer  language.  DARPA,  through  a  DoD  contract,  is  develop¬ 
ing  Ada,  which  is  a  high  order  software  language  to  support 
the  special  needs  of  embedded  computer  applications  such  as 
AUTODIN  II.  By  1981  there  should  be  sufficient  information 
to  decide  whether  Ada  is  a  viable  common  high  order  software 
language.  Plans  are  to  recode  the  I-S/A  AMPE  software  in 
this  high  order  language  with  implementation  by  1985. 

6.  WIN  Integration  into  AUTODIN  II. 

a.  Background.  This  subject  was  a  special  item  in 
the  IASA  Report  (Part  1)  and  is  herein  updated.  On  7  March 
1978,  ASD/C3I  approved  the  WWMCCS  Intercomputer  Network 


53 


(WIN)  Implementation  Plan,  directed  that  the  WIN  be  fully 
integrated  into  the  AUTODIN  II  by  December  1980,  and  requested 
that  an  integration  plan  be  forwarded  to  OSD  by  31  August 
1978.  On  1  April  1978,  the  Prototype  WIN  (PWIN)  was  re¬ 
designated  as  the  WIN.  In  December  1978,  the  JCS  distributed 
a  draft  plan  for  the  transition  of  the  WIN  to  AUTODIN  II. 

The  plan  includes  prerequisites  for  cutover,  discussion  of 
the  Network  Front  End  (NFE)  approach  and  a  cutover  schedule 
of  the  WIN  to  AUTODIN  II. 

b.  Requirements.  Five  WIN  requirements  of  AUTODIN 
II,  listed  as  prerequisites  prior  to  integration,  are:  1) 

AUTODIN  II  will  be  available  for  WWMCCS  use  by  April  1980; 

2)  stable  AUTODIN  II  system  performance,  including  accreditation 
to  a  security  level  of  at  least  TOP  SECRET;  3)  operational 
network  front-end  to  be  available  by  July  1980;  4)  equipment 
for  the  NFE  to  be  acquired  under  Air  Force  contract  from 
standard  WWMCCS  equipment;  5)  operational  AUTODIN  II  PSNs  at 
five  CONUS  locations  prior  to  final  cutover  of  WWMCCS  computers 
to  AUTODIN  II. 

•a 

c.  Approach.  By  ASD/C  I  direction,  the  WIN  should 
should  transition  to  AUTODIN  II  by  December  1980.  Based 
upon  the  transition  issues  to  be  resolved,  it  is  unlikely 
that  the  cutover  date  of  December  1980  can  be  met,  and  the 
October  1981  date  presented  in  the  JCS  plan  is  more  realistic. 

7.  Tactical  Systems  Interface  to  AUTODIN .  By  TRI-TAC 
Program  definition,  tactical  systems  will  be  interoperable 
with  current  and  planned  DCS  networks.  The  general  mode  of 
circuit  verfication  and  system  control  between  the  DCS  and 
tactical  systems  will  initially  be  manual,  with  a  goal  of 
increasing  automation  between  control  elements  on  a  cost- 
effective  basis. 

a.  Interface  Elements.  The  TRI-TAC  System  Archi¬ 
tecture  describes  two  facilities  as  interfacing  with  AUTODIN: 

(1)  the  AN/TYC-39  Store  and  Forward  Module;  and  (2)  the 

Modular  Tactical  Communication  Center  (MTCC).  The  tactical  systems 
interfacing  to  AUTODIN  are  illustrated  at  Figure  9. 

b.  AN/TYC-39  Store  and  Forward  Module.  The  AN/TYC- 
39  will  be  evaluated  as  a  potential  I-S/A  AMPE  candidate, 
but  it  is  expected  to  require  significant  upgrading  to 
include  AMPE  functional  capabilities.  The  AN/TYC-39  will  be 
delivered  during  FY  1982  and  its  availability  should  coincide 
with  the  deployment  and  retention  schedule  of  the  Inter- 
Service  /Agency  AMPE.  Access  to  the  AUTODIN  should,  as  a 
minimum,  be  the  Mode  I  protocol. 
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TACTICAL  SYSTEMS /AUTODIN  INTERFACE 
FIGURE  9 


c.  MRTT .  The  MRTT  is  a  family  of  terminals,  presently 
including  the  Modular  Tactical  Communications  Center  (MTCC) 
and  the  Single  Subscriber  Terminal  (STT) .  Both  terminals 
should  provide  access  to  the  AUTODIN  using  the  Mode  I  protocol. 

(1)  MTCC.  The  MTCC  will  be  a  tactical  communi¬ 
cations  center  including  processor /controller ,  auxiliary 
storage,  COMSEC  interface,  and  combinations  of  Unit  Level 
Message  Switch  (ULMS) ,  SST,  OCRs  and  other  peripherals. 

Access  to  the  AUTODIN  should  be  in  Mode  I  protocol. 

(2)  SST.  The  SST  provides  access  to  the  AUTODIN 
in  selectable  Modes  I,  II,  or  V.  The  SST  can  have  variable 
configurations,  but  the  primary  configuration  is  a  keyboard/ 
display  terminal  with  auxiliary  memory.  It  should  be  deployed 
at  the  tactical  unit  level  or  as  part  of  the  MTCC. 

8 .  Survivability . 

a.  General.  The  mid-term  architecture  should  be 
designed  to  function  effectively  during  peacetime  and  non- 
peacetime  conditions  ranging  from  localized  crises  situations 
to  worldwide  disruptions.  To  create  this  degree  of  reliability, 
the  mid-term  architecture  should  reflect  a  robust  telecommuni¬ 
cations  system,  capable  of  supporting  continued  command  and 
control  operations.  Interoperability  with  the  US  Allies  is 
a  prerequisite  for  establishing  a  flexible  and  survivable 
system  overseas.  Specific  RDT&E  attention  has  been  given  to 
increasing  the  ability  of  the  DCS  to  meet  system  survivability 
requirements  and  to  provide  the  capability  of  rapidly  recon¬ 
figuring  the  system  to  meet  changing  military  reauirements ; 
to  correct  deficiencies  that  exist  in  digital  transmission 
facilities  and  interactive  data  transfer  capability;  and  to 
increase  the  ability  to  handle  computer- to-computer  data 
traffic . 


b.  Approach.  A  major  design  criteria  in  the  mid¬ 
term  AUTODIN  architectural  work  has  been  to  enhance  surviv¬ 
ability  of  network  elements  in  the  evolutionary  development 
of  the  IAS.  The  mid-term  architecture  moves  switch  functions 
closer  to  the  user  by  use  of  the  I-S/A  AMPE.  This  approach, 
in  consonance  with  recent  planning  efforts  for  DCS  architec¬ 
tures,  will  reduce  the  dependency  on  the  more  vulnerable 
backbone  switches  and  should  enhance  overall  survivability.  For 
instance,  although  economics  have  driven  previous  decisions 
to  collocate  AUTODIN  I  switching  centers  with  AUTODIN  II 
packet  switching  nodes,  the  need  to  enhance  survivability  of 
these  network  elements  is  under  evaluation  to  determine 
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future  siting  of  these  facilities.  Several  development 
areas  associated  with  achieving  enhanced  IAS  survivability 
include:  (1)  conventional  hardening  of  key  nodes/sites;  (2) 

design  of  new  facilities  with  improved  physical  and  electro¬ 
magnetic  pulse  survivability;  (3)  interoperability  and 
mutual  support  agreements  with  other  networks;  (4)  transmission 
diversity  and  redundancy;  and  (5)  use  of  TRI-TAC,  foreign 
national  and  other  allied  military  communications  for  AUTODIN 
system  augmentation  and  restoral. 

9.  NATO  Interface  to  AUTODIN. 

a.  In  the  IAS  mid-term,  interface  between  US  and 
NATO  will  be  through  the  NATO  Integrated  Communications 
Systems/Telegraph  Automatic  Relay  Equipment  (NICS/TARE) . 

The  NICS/  TARE  will  be  an  enhancement  of  the  former  Telegraph 
Automated  Relay  Equipment  (TARE)  system.  The  automated 
NICS/TARE  system  will  connect  directly  to  AUTODIN  I  ASCs  via 
Allied  Relay  Stations. 

b.  The  formats,  protocols  and  AUTODIN  nodes  used  in 
the  interface  are  based  upon  US/NATO  agreements,  and  have 
been  factored  into  the  IASA  mid-term  design.  The  interface 
between  AUTODIN  I  and  the  NICS/TARE  will  be  a  modified  Mode 

I  terminal  interface  to  provide  the  basic  access  interface 
protocol.  Although  this  interface  is  not  considered  optimal 
for  the  eventual  integrated  system  operation,  it  is  not 
considered  feasible  in  the  near-term  to  accomplish  significant 
protocol/ interface  modifications.  Implementation  of  new 
access  arrangements  for  NATO  users  of  the  AUTODIN  should  be 
accomplished  in  the  mid-term. 


SECTION  III 

SYSTEM  ARCHITECTURE  (1984-1988 


A.  General.  The  purpose  of  this  section  is  to  provide  mid¬ 
term  {T9F5^1988)  AUTODIN  system  architecture  alternatives 
and  recommendations  for  major  network  elements  to  include 
packet  switching  nodes,  access  area  exchanges  and  terminals. 

The  IAS  Architecture  is  a  system- level  description  which 
considers  all  the  user  motivated  functions  (e.g.,  plain 
language  addressing)  and  system-motivated  functions  (e.g., 
routing)  required  for  end-to-end  data  communications  and 
teleprocessing  services,  allocates  these  functions  to  a 
feasible  subset  of  the  set  of  all  possible  elements  (e.g., 
nodes,  multiplexers,  terminals,  etc),  partitions  the  elements 
into  levels  (i.e.,  backbone,  local  and  regional  access 
area),  specifies  the  transmission  media  and  connectivity 
policy  for  interconnecting  the  various  elements  and  network 
levels,  and  describes  the  method  of  system  operation.  In 
doing  so,  hardware  and  software  features  are  included,  and 
the  way  in  which  the  elements  are  interconnected  into  a 
network  topological  structure  are  specified.  Protocols, 
interfaces,  routing  methods,  and  other  operational  and 
control  procedures  which  determine  how  the  interconnection 
and  operation  of  elements  provide  the  required  service  to 
the  user  are  stipulated. 

The  IAS  Architecture  is  comprehensive  enough  to  allow  the 
development  of  requisite  functional  specifications  and  to 
allow  for  meaningful  costing  at  the  system  level.  For  those 
elements  which  already  exist  or  are  already  designed,  engi¬ 
neering  and  software  documentation  or  specifications  and 
planning  documents  are  incorporated  into  the  architectural 
description.  For  new  elements,  functional  specifications 
will  be  developed  to  complete  the  description. 

The  IAS  Architecture  establishes  the  necessary  elements  for 
the  orderly  growth  of  DoD  data  communications,  and  should 
provide  decision  makers  with  the  requisite  criteria,  in 
terms  of  planning  and  costing  data,  to  make  accurate,  timely 
and  meaningful  decisions.  Decisions  predicated  on  the  IAS 
Architecture  will  be  founded  upon  a  total  terminal-to- 
terminal  system  design,  eliminating  functional  duplication 
and  enabling  a  cost-effective  approach  to  the  acquisition  of 
needed  communications  capability.  The  approved  IAS  Architec¬ 
ture  should  be  the  basis  from  which  the  detail  design  can 
begin.  Designers  will  rise  the  IAS  Architecture  as  technical 


and  policy  guidance  to  prepare  development  plans  for  obtaining 
the  hardware  and  software  needed  to  advance  from  the  near- 
term  (1978-1983)  architecture  to  the  mid-term  (1984-1988) 
architecture. 

B.  The  Mid-Term  IAS  Architecture.  In  the  mid-term  the 
architecture  should  provide  many  value-added  capabilities  to 
the  user  which  require  a  large  measure  of  data  processing 
power  within  the  network.  Two  basic  architecture  approaches 
that  can  provide  this  processing  power  are  to  centralize 
processing  in  a  small  number  of  network  nodes  and  use  high 
performance  computers  or  to  distribute  processing  power 
throughout  the  network.  The  process  of  defining  a  central¬ 
ized  or  distributed  mid-term  architecture  is  constrained  to 
consider  only  those  architectural  alternatives  which  are 
technically  and  economically  feasible.  The  architecture 
alternatives  described  in  the  succeeding  paragraphs  are 
consistent  with  the  objectives  and  the  evolutionary  approach 
of  the  IASA  project. 

C.  Architecture  Alternatives.  In  order  to  insure  that 
all  potential  mid-term  architectures  were  considered,  a 
number  of  architectures  were  identified  as  part  of  the 
technical  analyses  performed  in  support  of  the  IAS  architec¬ 
ture  definition.  These  architectures  were  generated  through 
a  sequential  decision  tree  approach  based  on  three  major 
architectural  decision  levels: 

.  Selection  of  an  element  set  from  among  the  available 
candidate  elements  discussed  in  Section  II. 

.  Allocation  of  functions  among  the  selected  element 
set. 

.  Consideration  of  specific  configuration/connecti¬ 
vity  options  within  the  architecture  (e.g.,  dual/ 
single  homing  of  nodal  elements). 

This  definition  process  resulted  in  the  identification  of  23 
architectures.  Upon  analysis  of  the  characteristics  of  the 
architectures,  it  was  determined  that  these  architectures 
could  be  organized  into  three  major  classes.  Further,  it 
was  determined  that  within  each  major  class  the  differences 
between  architectures  were  not  sufficient  to  significantly 
Impact  the  potential  cost  and/or  performance  of  the  resultant 
system  architecture.  Therefore,  three  final  architectures 
were  selected  for  evaluation  by  choosing  the  most  representa¬ 
tive  and/or  desirable  from  within  each  major  class.  These 
three  final  alternative  architectures  are  described  in  the 
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following  sub- sections.  These  three  architectural  alternatives 
use  the  packet  switched  node  (PSN)  as  the  principal  backbone 
switching  element  and  the  Inter-Service/Agency  AMPE  (I-S/A 
AMPE)  as  the  principal  access  area  message  processing  and 
communications  concentration  element.  In  addition,  all 
three  alternate  architectures  should  provide  the  required 
IAS  user  network  services  and  functions  defined  in  Section 
II. 

1.  Alternative  I. 

a.  General.  This  alternative  presents  a  centralized 
architecture  with  little  or  no  hierarchical  structure  in  the 
access  area.  All  network  and  user  services  in  this  alternative 
are  provided  from  a  small  number  of  service  elements  connected 
to  the  backbone  and  accessed  via  the  network. 

b.  Elements.  The  major  elements  of  this  architecture 
are  the  PSN,  I-S/A  AMPE,  CSF  and  subscriber  terminals. 

These  elements  and  their  application/role  in  the  architecture 
are  discussed  in  the  following  sub- paragraphs. 

(1)  Packet- Switching  Node  (PSN) .  The  mid-term 
architecture  will  use  the  PSN  (described  in  Section  II.B.l.b) 
as  the  backbone  switching  element  for  the  mid-term  IAS.  The 
AUTODIN  II  PSN  will  not  require  any  anticipated  modifications 
to  fill  this  role.  The  security  subsystem  (access  control 
and  key  variable  distribution)  can  be  implemented  in  a 
separate  host  computer  connected  to  the  PSN  via  the  network 
for  ease  of  transition.  (See  Appendix  4)  The  PSN  of  the  mid¬ 
term  architecture  will  continue  to  require  the  TAC 
capability  to  terminate  character  oriented  subscribers.  In 
addition,  the  ability  of  the  PSN  to  terminate  AUTODIN  I, 

Mode  I  subscribers  through  use  of  a  predefined  segment 
leader  will  be  retained  in  the  mid-term.  No  changes  are 
anticipated  to  the  normal  routing  procedures  implemented  in 
the  PSN.  New  contingency  routing  schemes  will  be  accomplished 
m  the  preferred  architecture  within  other  network  elements 
such  as  the  I-S/A  AMPE. 


Tho  r  ca  Inter- Service/ Agency  AMPE  (I-S/A  AMPE). 

he  I  S/A  AMPE  is  used  in  the  mid-term  architecture  as  both 
a  local  message  processing  service  element  and  a  limited 
communications  network  front-end.  A  simplified  block  diagram 

{^^?^8/HU!trated  in  Figure  10*  As  indicated, 
the  I-S/A  AMPE  will  include  the  same  Segment  Interface 
Protocols  (SIP)  and  Transmission  Control  Protocol  (TCP) 
functions  contained  in  a  PSN  TAC  and  will  function  as  a 


MOM  VI  TO  HNI 


—  14/A  AMTI  |(l  ONLY 


INTER-SERVICE/AGENCY  AMPE 
FIGURE  10 
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remote  TAC  to  the  PSN.  In  addition,  the  1-S/A  AMPE  will 
include  THP  and  terminal  control  functions  needed  to  provide 
AUTODIN  I  service  for  AUTODIN  II  character-oriented  subscribers, 
all  functions  necessary  to  act  as  an  AMPE  replacement,  and 
store- and- forward  processing  functions  needed  to  interface 
AUTODIN  I  terminals.  In  addition  to  terminating  both  AUTODIN 
I  and  AUTODIN  II  type  subscribers,  the  I-S/A  AMPE  will 
provide  the  terminal  support  functions  (PLA/RI *conversion, 
format  validation,  etc.)  needed  to  support  user  terminals 
that  require  such  services. 

(a)  In  its  role  as  a  limited  network  front 
end,  the  I-S/A  AMPE  will  incorporate  network  protocols  and 
processing  capabilities  that  will  permit  most  simple  direct 
terminal- to- terminal/host  transactions  to  take  place  without 
the  involvement  of  other  higher  level  service  elements 
except  the  PSN  switches.  As  a  result  of  this  capability, 
the  I-S/A  AMPEs  will  significantly  contribute  to  more  efficient 
use  of  backbone  facilities  and  improve  survivability. 

Further,  the  I-S/A  AMPE  will  forward  traffic  from  subscribers 
requiring  higher  level  service  to  the  appropriate  network 
CSF.  However,  unlike  the  current  system  of  dedicating 
"home"  service  elements,  the  I-S/A  AMPE  will  be  able  to 
forward  traffic  to  any  element  in  the  network  capable  of 
providing  the  service.  This  capability  will  allow  dynamic 
load  balancing  among  the  higher  level  elements  in  normal 
conditions,  and  provide  a  method  cf  contingency  recovery  in 
the  event  of  loss  of  a  service  element. 

(h)  The  I-S/A  AMPE  will  replace  all  current 
AMPEs  but  not  on  a  one-for-one  basis.  Due  to  its  standardized 
implementation/operation,  the  I-S/A  AMPE  should  satisfy 
Service/Agency  requirements.  This  will  allow  consolidation 
of  current  AMPE  locations  with  no  reduction  in  service. 

..  O)  Central  Service  Facility  (CSF).  The  CSF 

provides  ASC  support  functions  for  subscribers  connected  to 

'r^Ns^o2dJnew  JAS  functions  for  subscribers  in  the  network. 

s  CSF  interfaces  to  one  or  more  PSNs  as  a  host  computer 
It  does  not  terminate  subscribers. 

(4)  Subscriber  Terminals.  As  previously  stated, 

ATTTnnrw  ?ermjIA?  will  have  to  8UPPort  all  existing  types  of 
AUTODIN  I  and  planned  AUTODIN  II  terminals.  It  is  also 

expected  that  terminals  with  additional  capabilities  will  be 

AiTTnn?MC^d  t?e  mi<?:term  as  Part  of  the  common  family  of 
£2™?i?iter7J?als*  Although  increased  capability  in  some 
terminals  will  not  relieve  the  network  of  supporting  the 
remainder  of  less  capable  terminals,  it  can  reduce  the 
processing  load  on  the  network  and  reduce  the  dependence  of 


the  terminels  on  other  network  elements.  A  summary  of 
anticipated  mid-term  subscriber  terminal  characteristics  is 
shown  in  Table  5. 

c.  Configuration/Connectivity.  Configuration  of 
the  network  elements  is  illustrated  in  Figure  11.  The 
connection  options  for  Alternative  I  are  illustrated  in 
Figure  12.  AUTODIN  I  terminals  connected  to  PS Ns  will  be 
serviced  by  the  CSF.  The  CSF  connects  only  to  PSNs  and  uses 
an  AUTODIN  II,  Mode  VI,  Binary  Segment  Leader  host  interface 


TABLE  5 


MID-TERM  IAS* TERMINAL  CHARACTERISTICS 


TYPES  -  All  AUTODIN  I  and  AUTODIN  II  types  plus  common 
family  of  terminals  to  include  more  intelli¬ 
gent/capable  terminals. 

PROTOCOLS  -  All  AUTODIN  I  and  AUTODIN  II  protocols  plus 
additional  unique  link  protocols  (e.g. ,  AMPE 
user  protocols)  and  new  end-to-end  protocols 
{e.g. ,  Virtual  Message  Protocol) 

CODES  -  ASCII  and  ITA#2  (others  transparent) 

SPEEDS  -  45.5bps  -  56K  bps 

FORMATS  -  AUTODIN  II  Segment  Formats.  JANAP  128.  ACP 
126/127,  DOI  103,  DD-173 


ALTERNATIVE  I  CONNECTIVITY 
FIGURE  12 


d.  Protocols.  Alternative  I  requires  the  develop¬ 
ment  of  at  least  one  new  network  level  protocol.  This 
protocol,  called  the  Virtual  Message  Protocol  (VMP)  will 
support  direct  exchange  of  message  information  among  I-S/A 
AMPEs  via  the  PSN  backbone.  Additional  network  level  and 
even  link  level  protocols  may  be  identified  in  the 
process  of  further  defining  the  mid-term  network  services 
and  operating  procedures.  However,  these  protocols  will  be 
implemented  only  in  the  IAS  mid-term  elements.  No  additional 
protocols  are  required  in  existing  elements  to  support  the 
preferred  architecture.  This  is  a  significant  consideration 
in  the  evolutionary  development  of  the  mid-term  IAS  network. 
The  anticipated  link  and  network  level  protocols  and  their 
use  in  this  alternative  are  discussed  further  in  the  following 
sub- paragraphs . 

(1)  Link  Protocols.  The  link  level  protocols 
anticipated  between  mid-term  elements  are  summarized  in 
Figure  13. 

(2)  Network  Level  Protocols.  The  mid-term 
architecture  makes  use  of  the  protocol  layers  defined  for 
AUTODIN  11.  The  1-S/A  AMPE  will  operate  through  the  network 
using  host-type  protocols,  i.e.,  they  will  employ  the  Segment 
Interface  Protocol  (SIP)  and  Transmisstion  Control  Program 
(TCP).  In  addition,  they  will  use  a  Virtual  Message  Protocol 
(VMP)  for  exchanging  message  traffic  through  the  packet 
network.  The  VMP  will  include  functions  necessary  for 
routing  and  accountability  of  narrative /record  traffic  (most 
of  which  are  presently  provided  by  the  ASCs)  such  as  message 
acknowledgements,  rejections,  cancellations,  service  message 
generation,  and  message  control  block  functions.  The  network 
level  protocols  required  for  the  mid-term  IAS  architecture 
are  defined  in  the  following  sub- paragraphs . 

(a)  Switch- to- Switch  Protocols.  Switch- 
to- Switch  protocols  are  defined  for  AUTODIN  II  PS Ns  to 
accomplish  routing,  accountability  and  flow  control  between 
local  and  source/destination  packet  switches.  These  protocols 
are  not  changed  by  the  mid-term  architecture. 

(b)  Host- to-Switch  Protocol.  The  protocol 
used  between  PSNs  and  AUTODIN  II  hosts  and  between  PSNs  and 
I-S/A  AMPEs  is  the  SIP,  accomplished  through  the  exchange  of 
binary  segment  leaders. 
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•  THESE  CONNECTIONS  WILL  BE  CONSIDERED  ON  A  CASE-BY-CASE  BASIS. 

••  ALL  AMPES  DO  NOT  HAVE  ALL  MODES. 

TO  BE  ADDRESSED  UNDER  ALTERNATIVE  II 
NA  -  NOT  APPLICABLE 

I  -  AUTODIN  I  MODE  I,  CHARACTER  SYNCHRONOUS 

IB  -  AUTOOIN  II  MODE  IB,  CHARACTER  SYNCHRONOUS 

II  -  AUTOOIN  I  MOOE  II.  CHARACTER  ASYNCHRONOUS  (UNCONTROLLED) 

It  A  -  AUTODIN  II  MODE  II.  CHARACTER  ASYNCHRONOUS 
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VI  -  AUTOOIN  II  MOOE  VI.  BINARY  SYNCHRONOUS 

HS  -  HOST  SPECIFIED 

SS  -  SUBSCRIBER  SPECIFIED 


MID-TERM  LINK  PROTOCOLS 
FIGURE  13 


(c)  Host-to-Host  Protocols.  Host-to-Host 
protocols  refer  to  the  general  set  of  protocols  used  between 
host  computers  or  automated  message  exchanges  communicating 
through  the  network.  They  include  the  Transmission  Control 
Protocol  (TCP)  and  other  host-specific  protocols.  The  I-S/A 
AMPEs  and  CSF  will  use  the  TCP  for  communicating  through  the 
network  with  host  computers,  other  I-S/A  AMPEs  and  CSFs  and 
part  of  PSN  or  I-S/A  AMPE.  In  addition,  the  I-S/A 

AMPEs  will  use  the  VMP  for  exchanging  narrative /record 
traffic  among  themselves  and  with  other  hosts  of  automated 
message  processing  facilities  which  employ  the  VMP. 

(d)  Terminal- to-Host  Protocols.  Terminal - 
to-Host  protocols  refer  to  the  general  set  of  protocols 
which  allow  terminals  to  interact  with  hosts  or  message 
processing  elements.  The  standard  AUTODIN  II  Terminal- to- 
Host  Protocol  (THP)  will  be  used  in  the  mid-term  architecture 
for  this  purpose.  The  THP  supports  terminal- to- terminal  and 
terminal- to-process  transactions  by  making  the  various 
terminals  and  processes  appear  as  similar  as  possible  to 
users.  These  transactions  require  interaction  between 
source  and  destination  THPs  and  between  the  THPs  and  the 
terminals  and  host  processes.  In  AUTODIN  II,  the  THP  is 
implemented  in  host  computers  and  PSN  TACs.  Since  the  I-S/A 
AMPEs  will  provide  a  TAC  capability  for  AUTODIN  II  subscribers , 
they  will  also  implement  the  THP.  The  elements  which  directly 
terminate  subscribers  must  also  incorporate  terminal  handlers, 
or  terminal  control  protocols  tailored  to  the  characteristics 
of  the  specific  terminals. 

(e)  User-to-User  Protocols.  User-to-user 
protocols  are  the  procedures  effected  between  end  users  of 
the  network  (where  the  end  users  may  be  terminal /system 
operators  or  software  processes)  through  exchange  of  control 
information  and  message  format.  The  packet  switch  network 
and  the  protocol  levels  described  are  transparent  to  the 
user-to-user  protocols.  User-to-user  protocol  includes  such 
functions  as  user  interaction  with  host  software  processes 
and  end-to-end  security  functions.  Message  format  instruction 
for  message  distribution  and  handling  by  I-S/A  AMPEs,  CSFs 
AMPEs  and  terminals,  such  as  transmission  release  codes, 
office  symbols,  flagwords  or  references  are  also  considered 
within  the  class  of  user- to  user  protocols  for  the  purposes 

of  this  protocol  definition. 
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Figure*  14  and  15  show  example*  of  the  application  of  the 
classes  of  protocols  described  above.  Figure  14  shows  the 
primary  layers  of  protocols  required  for  a  transaction 
between  an  AUTODIN  II  terminal  and  a  PSN  connected  host 
computer.  (Additional  protocol  layers  exist  which  are  not 
shown  in  this  and  other  diagrams,  such  as  originating  terminal 
to  destination  host  and  originating  host  to  destination  PSN. 
Also  not  shown  are  link  level  protocols).  In  this  example, 
the  TAC  equivalent  functions  in  the  I-S/A  AMPE  provide  host 
level  protocols. 
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Figure  IS  show*  the  network  protocols  for  an  AUTODIN  I 
transaction  between  I-S/A  AMPE  and  CSF  connected  subscribers. 
In  this  case  the  VMP  is  employed  between  the  X-S/A  AMPEs  and 
CSFs  to  control  the  exchange  of  narrative /record  messages 
through  the  network.  A  user-to-user  level  protocol  is  shown 
between  the  I-S/A  AMPEs  and  CSFs  which  Includes  messsge  for¬ 
mat  processing  such  as  distribution  instructions.  The  THP 
used  for  AUTODIN  II  type  transactions  does  not  apply  in  this 
case. 


"1 
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e.  Functional  Allocation.  The  allocation  of  functions 
to  network  elements  in  the  Alternative  I  architecture  is 
summarized  in  Figure  16.  In  order  to  illustrate  the  evolutionary 
transition  required  from  the  near-term  to  the  mid-term. 

Figure  16  includes  the  current  near-term  AUTODIN  elements 
ana  illustrates  their  functional  capabilities.  As  noted  in 
Section  II,  the  functions  required  for  the  basic  AUTODIN  I 
narrative/  record  message  transfer  service  can  be  generally 
categorized  as  subscriber  support  functions  (e.g.,  code  and 
format  conversion,  message  retrieval)  and  network  functions 
(e.g.,  multiple/collective  routing).  In  the  Alternative  1 
architecture,  the  subscriber  support  functions  are  allocated 
to  the  I-S/A  AMPE  because  they  are  most  effectively  performed 
at  a  point  near  the  subscribers,  and  because  many  of  these 
functions  are  already  performed  in  the  existing  AMPEs.  In 
addition,  the  I-S/A  AMPE  is  also  assigned  the  AUTODIN  II 
terminal  access  functions  and  a  Mode  VI  host-type  interface 
to  the  PSN  and  the  CSF  both  to  provide  flexibility  for 
subscriber  termination  to  the  network,  and  to  ensure  an 
efficient,  high  speed,  network  access. 

f.  Operational  Characteristics.  The  operational 
characteristics  of  Alternative  1  in  the  areas  of  traffic 
flow,  security,  and  system  control,  are  described  in  the 
following  paragraphs. 

(1)  Traffic  Flow.  The  flow  of  traffic  through 
the  network  is  described  in  the  following  subparagraphs  for 
different  types  of  traffic  originated  by  subscribers  connected 
to  each  of  the  major  network  elements.  There  are  two  basic 
types  of  subscribers  expected  in  the  mid-term  IAS.  The 
first  type  of  subscriber  may  have  terminal  equipment  (including 
AMPE)  which  will  support  only  AUTODIN  I  operation.  The 
second  type  of  subscriber  expected  in  the  mid-term  IAS  Is 
computer  host  or  AUTODIN  II  subscriber.  In  the  following 
discussion  these  are  referred  to  as  AUTODIN  I  and  AUTODIN  II 
subscribers  respectively.  Either  type  may  be  connected  to  a 
CSF  through  the  PSN  or  to  an  I-S/A  AMPE. 

(a)  AUTODIN  I  Subscribers.  Traffic  entered 
to  an  I-S/A  AMPE  from  AUTODIN  I  subscribers  will  be  formatted 
in  an  AUTODIN  I  format  and  addressed  with  a  routing  indicator 
(RI)  or  Plain  Language  Address  (PLA) .  It  will  be  automatically 
transferred  to  the  store-and- forward  portion  of  the  I-S/A 
AMPE  where  AMPE  and  AUTODIN  I  functions  are  performed.  If 
the  message  requires  services  not  provided  by  the  I-S/A 
AMPE,  it  will  be  forwarded  through  the  PSN  network  to  a  CSF. 

If  CSF  services  are  not  required  the  message  will  be  distributed 
locally  as  necessary  and/or  forwarded  through  the  PSN  network 
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with  other  I-S/A  AMPEs  will  allow  the  transfer  of  information 
concerning  the  origin  of  the  message  and  processing  required 

(b)  AUTODIN  II  Subscribers.  These 
Subscribers  will  be  in  AUTODIN  I  or  AUTODIN  II  format.  The 
AUTODIN  I  format  messages  will  be  transferred  to  the  store* 
and* forward  portion  of  the  1-S/A  AMPE  and  processed  as 
*  described  above.  For  AUTODIN  II  format  transactions,  the  I- 
S/A  AMPE  will  perform  PSN  TAC  equivalent  functions,  segment 
the  data  and  forward  it  to  the  PSN.  The  PSN  will  accept 
traffic  one  segment  or  character  at  a  time  from  the  subscriber, 
make  prescribed  control,  security  and  community  of  interest 
checks,  format  the  segment  into  a  packet  for  network  trans¬ 
mission  and  send  each  packet  separately  into  the  network  on 
the  appropriate  trunk. 

(2)  Security.  The  security  subsystem  for  the 
Alternative  1  mid-term  architecture  should  provide^the 
capability  to  support  both  end-to-end  encrypted  (E-5)  users 
and  link  encrypted  users.  It  is  expected  that  this  mix  of 
EJand  non-EJ  users  will  persist  throughout  the  mid-term  and 
well  into  the  far- term. 

3 

(a)  The  non-E  users  will  be  provided 
security  service  through  the  use  of  conventional  link  encryp¬ 
tion  techniques  such  as  those  employed  in  AUTODIN  I  and 
AUTODIN  II.  Non-E J  users  will  be  supported  by  a  variety  of 
link  encryption  devices.  Non-E  users  will  be  afforded  end- 
to-end  security  in  the  mid-term  IAS  through  a  combination  of 
link  encryption  and  security  kernels  used  in  the  IAS  network 
elements.  These  users  will  also  be  provided  with  traffic 
flow  security  protection  through  the  inherent  features  of 
the  link  key  generators  employed  for  encryption/decryption . 
This  class  of  user,  however,  will  not  be  provided  with 
automatic  access  control,  user  authentication,  or  on-line 
key  distribution. 


(b)  The  E-*  users  will  be  provided  service 
through  the  application  of  BLACKER  hardware  and  supporting 
security  software  integrated  in  the  various  system  elements 
of  the  IAS.  The  allocation  of  BLACKER  components  to  the  IAS 
elements  is  discussed  in  Appendix  4.  EJ  subscribers  should 
be  capable  of  accessing  network  services  (e.g.,  message 
processing,  mailbox,  teleconferencing),  as  well  as  other  EJ 
subscribers.  Furthermore,  EJ  subscribers  and  non-E3  sub¬ 
scribers  should  be  able  to  access  each  other. 

(3)  System  Control.  The  Alternative  I  mid¬ 
term  architecture  will  make  use  of  available  and  planned  DCS 
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system  control  capabilities  and  resources.  This  architecture 
does  not  require  changes  to  the  system  control  functions  of 
the  AUTODIN  II  PSNs  and  Network  Control  Center  (NCC) . 
Introduction  of  the  I-S/A  AMPE  and  CSF  will  allow  monitoring, 
control,  reporting  and  restoral  functions  to  be  performed  at 
various  levels  in  the  network  and  thus  improvements  should 
be  realized  in  efficiency  and  reaction  time. 

As  major  message  processing  elements  the  I-S/A  AMPE  and 
CSF  must  perform  most  of  the  system  control  functions  performed 
by  the  ASC  and  some  of  those  performed  by  the  PSN.  The 
Automated  Technical  Control  (ATEC)  improvement  will  be 
completed  prior  to  implementation  of  these  elements,  and 
they  should  have  the  ATEC  Station  level  capabilities.  Table 
6  lists  the  major  system  control  functions  required  in  the 
I-S/A  AMPE  and  CSF. 

Since  the  I-S/A  AMPE  will  terminate  the  majority  of 
narrative/record  subscribers  in  the  system  it  will  be  neces¬ 
sary  for  them  to  collect  and  report  subscriber  traffic 
statistics  for  billing  purposes.  They  will  also  record  the 
status  information  and  statistics  necessary  to  support 
system  engineering  and  traffic  management. 

2.  Alternative  II. 

a.  General.  This  alternative  represents  a  distributed 
architecture  in  which  user  and  network  services  are  provided 
from  a  common  access  area  element.  This  results  in  a  flexible 
structure  in  the  access  area  with  services  accessed  both 
directly  and  via  the  backbone  network.  In  addition,  this 
architecture  provides  the  maximum  degree  of  commonality 

among  network  elements. 

b.  Elements.  The  major  elements  of  Alternative  II 

are  the  PSN,  I-S/A  AMPE(E) ,  I-S/A  AMPE  and  subscriber  terminals. 
This  alternative  does  not  include  a  CSF. 

(1)  The  PSN,  I-S/A  AMPE  and  subscriber  terminals 
used  in  Alternative  II  are  the  same  elements  as  those  discussed 
in  Alternative  I  and  will  not  be  repeated. 

(2)  Inter- Service/ Agency  AMPE  Enhanced  (I-S/A  AMPE 
(E)  Phase  II).  The  I-S/A  AMPE(E)  will  fulfill  the  two  distinct 
roles.  It  will  function  as  a  normal  I-S/A  AMPE  for  its 
locally  connected  subscribers.  In  this  role  it  will  provide 
local  terminal  support  and  message  processing  functions  and 

act  as  the  network  front  end.  Secondly,  the  I-S/A  AMPE(E) 
will  serve  as  a  network  service  i|2fement.  In  this  role  the 
I-S/A  AMPE(E)  will  provide  netwo^c  services  to  both  locally 


TABLE  6 


CSF  AND  I-S/A  AMPE  SYSTEM  CONTROL  FUNCTIONS 
Network  Control  Functions 

*  .  Patch  and  Test  Facility 

*  Intersystea  Interface 
Internal  Control 

-  Res tart /recovery 

-  Prograa/table  reload 
•  Diagnostics 

-  Hardware /software  monitoring 
Statistics  Generation 

(Circuit  Outage,  Circuit  Performance,  etc.) 

Circuit  Restoral/Reconfiguration 
Traffic  Control  Functions 
.  Message  Routing 

*  Message  Distribution 

Traffic  Flow  Control 

Traffic  Accountability  and  Integrity 

Status  Monitoring/Performance  Assessment 

(Traffic  conditions,  backlogs,  resource  utilization) 


*  NOTE:  I-S/A  AMPE  Functions  only 
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connected  and  remote  access  subscribers  throughout  the 
network.  As  a  network  service  element,  the  I-S/A  AHPE(E) 
will  support /augment  the  capability  of  the  lower  level  I-S/A 
AMPE  and  terminal  elements  by  performing  message/  data 
processing  services  that  require  processing  and/or  data 
storage  capacity  beyond  that  available  in  the  lower  level 
elements.  Typical  services  in  this  category  include:  code/ 
format  conversion;  message  exchange  with  systems  outside  the 
IAS;  file  storage,  update,  and  retrieval;  and  telecommuni¬ 
cations  conference  control  and  record  keeping.  Shared 
network  use  of  these  I-S/A  AMPE(E)  capabilities  will  signi¬ 
ficantly  reduce  the  processing  and  storage  requirement  of 
the  local  I-S/A  AMPE  and  terminal  equipments.  This  in  turn 
should  significantly  reduce  the  total  network  acquisition 
and  operating  cost  to  provide  a  given  level  of  network 
service.  The  I-S/A  AMPE(E)  will  be  developed  under  the  same 
program  as  the  I-S/A  AMPE  and  will  share  its  basic  software 
modules  with  the  I-S/A  AMPE.  The  block  diagram  contained  in 
Alternative  I  (Figure  10)  therefore,  is  also  applicable  to 
the  I-S/A  AMPE(E).  The  I-S/A  AMPE (E)  will  include  additional 
software  modules,  additional  hardware  processing  and  storage 
capacity,  and  additional  communi cat ions  interface  hardware/ 
software  than  the  basic  I-S/A  AMPE.  As  indicated  previously 
the  I-,S/A  AMPE(E)  installations  will  in  many  cases  be  accom¬ 
plished  by  retrofit/upgrade  of  previously  installed  I-S/A 
AMPEs . 


c.  Configuration/Connectivity.  The  basic  configu¬ 
ration  of  network  elements  is  illustrated  in  Figure  17. 

Figure  18  illustrates  all  single  connections  (both  preferred 
and  alternative)  between  elements.  As  indicated  in  this 
diagram,  AUTODIN  I  type  subscribers  (including  AMPEs)  connected 
to  PSNs  will  enter  messages  in  AUTODIN  I  formats  via  the  PSN 
TAC  and  all  of  their  traffic  will  be  automatically  routed 
(cut- through)  to  a  designated  I-S/A  AMPE(E)  for  processing. 

Since  the  PSNs  do  not  process  AUTODIN  I  precedence  and 
security  format  elements,  all  cut- through  traffic  will  be 
handled  at  the  highest  level  precedence  and  security.  For 
this  reason,  direct  connection  of  AUTODIN  I  type  subscribers 
to  I-S/A  AMPEs  or  I-S/A  AMPE(E)s  is  preferred  to  PSN  connection. 

(1)  Terminals  may  be  dual  homed  to  any  combination 
of  the  applicable  nodal  element  types,  i.e.,  PSN,  I-S/A 
AMPEs,  or  I-S/A  AMPE(E)s  may  be  connected  to  PSN  or  I-S/A 
AMPE(E)s  and  can  be  dual  homed  to  one  or  both  of  those 
elements  types.  Since  some  I-S/A  AMPE  traffic  will  require 
routing  to  an  I-S/A  AMPE(E)  for  service  and  some  will  be 
routed  directly  through  the  PSN  network,  the  preferred 
connectivity  for  an  I-S/A  AMPE  will  be  dual  connection  to 
both  a  PSN  and  an  I-S/A  AMPE(E).  Depending  on  the  specific 
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ALTERNATIVE  II  CONNECTIVITY 
FIGURE  18 


communities  of  interest  served  by  an  I-S/A  AMPE  and  the 
proportions  of  traffic  types,  it  will  be  possible  to  connect 
an  I-S/A  AMPE  to  either  one  of  those  element  types.  X-S/A 
AMPEs  will  not  normally  be  directly  interconnected,  but  for 
contingencies  may  connect  using  Mode  I  or  VI  protocols. 

(2)  I-S/A  AMPE(E)s  will  access  the  network 
directly  via  a  PSN.  They  will  normally  be  dual  homed  to  PSNs 
for  survivability. 

(3)  Tactical  and  NATO  system  interfaces  in 
AUTODIN  I  subscriber  modes  will  have  the  same  connection 
options  as  AUTODIN  I  terminals,  and  for  the  same  reasons, 
connection  of  AN/TYC-39  and  NICS  TARE  relays  to  an  I-S/A 
AMPE  or  1-S/A  AMPE(E)  is  preferred. 

(4)  The  interconnectivity  of  all  network  elements 
is  summarized  in  Figure  19.  The  connectivity  options  offered 
by  the  architecture  allow  flexibility  for  overseas  deployment. 
In  general,  the  backbone  IAS  network  will  be  extended  by 
locating  PSNs  overseas.  Alternatives  for  overseas  implemen¬ 
tation  are  discussed  in  Section  IV. 

d.  Protocols.  Alternative  IX  link  level  and 
network  level  protocols  are  the  same  as  for  the  correspond¬ 
ing  elements  in  Alternative  I.  Since  the  I-S/A  AMPE (E)  is  a 
modular  enhancement  of  the  I-S/A  AMPE,  the  protocol  examples 
provided  in  Alternative  I  Figures  13,  14,  and  15  apply. 

Figure  13  summarizes  the  link  protocols.  Figure  14  illus¬ 
trates  the  primary  layers  of  protocols  required  for  trans¬ 
actions  between  an  I-S/A  AMPE(E)  connected  AUTODIN  II  terminal 
and  an  AUTODIN  II  connected  host  computer.  Figure  15  shows 
the  network  protocols  for  an  AUTODIN  I  transaction  between 
I-S/A  AMPE(E)  connected  subscribers. 

e.  Functional  Allocation.  The  availability  of 
services  for  the  various  types  of  subscribers  is  about  the 
same  in  Alternative  II  as  in  Alternative  I.  The  only 
exception  is  that  the  functions  are  allocated  to  the  I-S/A 
AMPE(E)  Instead  of  the  CSF  (see  Figure  16). 

f.  Operational  characteristics.  Traffic  in  this 
architecture  alternative  will  flow  from  source  to  destination 
through  one  or  more  intermediate  nodes.  Narrative 

record  traffic  will  generally  flow  through  an 
Intermediate  I-S/A  AMPE(E)  and  will,  therefore,  receive 
necessary  terminal  support  and  network  service  processing 
enroute.  All  network  subscribers  will  access  network 
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MID-TERM  CONNECTIVITY  MATRIX 
FIGURE  19 


services  from  the  nearest  available  I-S/A  AMPE(E).  The 
Alternative  II  approaches  to  traffic  flow,  Security  and 
System  Control  are  addressed  in  the  succeeding  sub-paragraphs. 

(1)  Traffic  Flow: 

(a)  AUTODIN  I  connected  subscribers  to  an 
I-S/A  AMPE(E).  Traffic  submitted  to  the  1-S/A  AMPE(E)  from 
AUTODIN  I  subscribers  will  be  addressed  with  Plain  Language 
Addresses  (PLAs)  or  Routing  Indicators  (RIs)  and  may  be 
forwarded  in  any  one  of  the  AUTODIN  formats  (JANAP  128,  ACP- 
126-127,  DOI-103,  DD173.  This  traffic  will  be  automatically 
transferred  to  the  store- and- forward  message  processing 
portion  of  the  I-S/A  AMPE(E)  where  AMPE  and  AUTODIN  I  type 
functions  are  performed  (see  Figure  10) .  Local  distribution 
to  directly  connected  subscribers  (including  allied/ tactical) 
will  be  made  directly  from  the  I-S/A  AMPE(E)  as  required. 

The  I-S/A  AMPE(E)  will  segment  and  forward  the  messages, 
through  the  PSN  network,  to  the  destination  I-S/A  AMPE(E) , 

I-S/A  AMPE  or  PSN  -  connected  subscriber.  As  part  of  the 
Virtual  Message  Protocol,  the  originating  I-S/A  AMPE(E)  will 
provide  information  to  the  destination  I-S/A  AMPE  or  I-S/A 
AMPE(E)  concerning  the  origination  code  and  format  to  allow 
necessary  conversions  to  be  made  for  the  destination  subscriber. 
PSN  -connected  subscribers  that  are  transferred  to  the 
originating  I-S/A  AMPE (E)  will  be  treated  as  local  subscribers 
by  that  I-S/A  AMPE(E).  Transmission  logs,  histories  and 
retrieval  storage  will  be  maintained  at  the  basic  or  enhanced 
I-S/A  AMPE  unless  the  originating  subscriber  is  designated/ 
authorized  for  limited  privacy  service  in  which  case  no 
permanent  storage  of  the  message  is  maintained. 

(b)  AUTODIN  II  connected  subscribers  to  an 
I-S/A  AMPE(E).  These  subscribers  may  enter  traffic  in  any 
one  of  the  AUTODIN  I  formats  or  in  AUTODIN  II  formats.  The 
traffic  entered  in  AUTODIN  I  format  will  be  addressed  using 
FLA  or  RI.  It  will  be  forwarded  to  the  store-and-forward 
portions  of  the  I-S/A  AMPE(E)  and  handled  as  described 
above.  Traffic  entered  in  AUTODIN  II  format  will  provide 
segment  leader  information  with  each  transaction  and  the 
text  will  be  free  format,  i.e.,  the  message  format  may  be 
one  of  the  AUTODIN  I  formats  or  other  user-to-user  format. 

For  host  computer  transaction  transfers  requiring  no  addi¬ 
tional  processing,  the  I-S/A  AMPE(E)  segments  the  traffic 
and  forwards  it  to  a  PSN  for  routing.  No  local  routing  is 
done  for  this  type  of  traffic  by  the  I-S/A  AMPE(E).  The  I- 
S/A  AMPE  will  recognize,  via  segment  leader  designators, 
transactions  that  require  services  provided  only  by  an  I-S/A 
AMPE(E) ,  such  as  mailbox  or  teleconferencing,  and  will 
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forward  the  transaction  to  an  I-S/A  AMPE(E)  by  inserting  a 
segment  leader  with  the  I-S/A  AMPE(E)  address.  Otherwise, 
segments  will  be  relayed  through  the  I-S/A  AMPE  containing 
only  the  destination  address. 

(c)  AUTODIN  I  Connected  Subscribers  to  a 
PSN.  AUTODIN  I  subscribers  connected  to  PSNs  will  be 
automatically  transferred  to  a  designated  I-S/A  AMPE(E). 

All  traffic  generated  by  these  subscribers  will  be  automati¬ 
cally  routed  to  the  I-S/A  AMPE(E)  which  will  process  the 
traffic  as  if  it  came  from  a  local  AUTODIN  I  subscriber. 
Traffic  generated  by  AUTODIN  II  subscribers  connected  to 
PSNs  must  be  in  AUTODIN  II  format  with  segment  leader  infor¬ 
mation  provided.  Transactions  which  require  I-S/A  AMPE(E) 
services  will  be  addressed  to  an  I-S/A  AMPE(E)  since  the 
PSNs  will  not  recognize  the  need  for  such  services. 

(2)  Security.  Security  for  non-E  users  is 
provided  in  this  alternative  and  is  similar  to  that  of 
Alternative  I.  Also,  security  for  E  users  is  provided  in 
the  same  manner  as  in  Architecture  I  except  that  the  BLACKER 
elements  may  be  located  at  different  places  in  the  network. 
Trade-offs  for  location  of  these  elements  are  discussed  in 
Appendix  4. 


(3)  System  Control.  System  control  considera¬ 
tions  for  Architecture  II  differ  from  those  of  Architecture 
I  because  of  the  existence  of  I-S/A  AMPE(E)s  and  the  absence 
of  CSFs.  Since  the  I-S/A  AHPE(E)  services  narrative/record 
subscribers,  it  will  be  required  to  perform  all  the  system 
control  functions  of  the  CSF  of  Alternative  I.  The  same 
functions  apply  to  the  I-S/A  AMPE  in  Architectures  I  and  II. 
Table  6  lists  the  major  system  control  functions  required  in 
the  I-S/A  AMPE  and  the  CSF;  those  CSF  functions  apply  under 
this  alternative  to  the  I-S/A  AMPE(E) .  Although  the  functions 
listed  apply  to  both  the  CSF  and  I-S/A  AMPE(E)  elements,  the 
scope  of  the  functions  will  be  different.  For  example,  the 
1~S/A  AMPE(E)  will  collect  reports  from  a  number  of  I-S/A 
AMPEs  and  generate  a  consolidated  report  to  the  NCC  or  other 
DCS  control  centers. 

3.  Alternative  III. 

a.  General.  This  alternative  represents  a  hybrid 
architecture  between  the  centralized  structure  of  Alternative 
I  and  the  distributed  structure  of  Alternative  II.  In  this 
architecture,  some  services  are  provided  by  a  centralized 
backbone  service  element  and  some  services  are  provided  by 
a  distributed  access  area  element.  Figure  20  shows  the 
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major  elements  of  Architecture  III  and  their  interconnections'. 

b.  Elements.  The  major  elements  which  comprise 
Architecture  III  are  the  PSN,  I-S/A  AMPE,  I-S/A  AMPE(E) ,  CSF 
end  subscriber  terminals.  The  PSN,  I-S/A  AMPE,  and  subscriber 
terminals  are  the  same  elements  described  for  Architecture  I  and 
II.  The  I-S/A  AMPE(E)  is  the  same  as  described  for  Architec¬ 
ture  II  except  that  it  does  not  provide  the  new  IAS  network 
services.  As  in  Architecture  II,  the  I-S/A  AMPE(E)  performs 
the  AMPE  functions  and  ASC  terminal  support  and  network 
functions,  and  is  a  modular  enhancement  to  the  I-S/A  AMPE. 

A  Central  Service  Facility  (CSF)  is  provided  in  Architecture 
III  to  perform  the  new  functions  Identified  for  the  mid-term 
and  is  also  the  primary  expansion  element  to  assume  new 
functions  as  new  requirements  are  identified.  The  CSF 
connects  to  one  or  more  PSNs  as  a  host  computer.  Although 
it  provides  user  service  via  network  access,  it  does  not 
terminate  subscribers. 


c.  Configuration/Connectivity.  Connectivity 
options  for  all  common  elements  are  the  same  for  Architecture 
III  and  Architecture  I.  The  CSF  connects  only  to  PSNs  and 
uses  an  AUTODIN  II,  Mode  VI,  Binary  Segment  Leader  host 
interface.  Gateways  to  external  packet  networks  would  be 
implemented  in  the  CSF.  New  narrative/record  interfaces  to 
existing  tactical  elements  such  as  the  TYC-39  can  be  implemen 
ted  in  the  I-S/A  AMPE  or  I-S/A  AMPE(E). 

d.  Protocols.  As  for  Architecture  II,  Architecture 
III  requires  no  new  protocols  to  be  implemented  in  existing 
elements.  Link  level  and  network  level  protocols  are  the 
same  as  for  the  corresponding  elements  of  Architecture  II. 

The  CSF  will  communicate  through  the  PSN  network  with  other 
host  computers,  I-S/A  AMPEs,  I-S/A  AMPE(E)s  and  terminals  as 
a  host  computer  and  will  therefore  implement  SIP,  TCP  and 
THP  protocols. 

e.  Functional  Allocations.  The  availability  of 
services  to  the  various  types  of  subscribers  is  the  same  in 
Architecture  III  as  in  Architecture  II  except  that  some  of 
the  services  are  obtained  from  the  CSF  instead  of  the  I-S/A 
AMPE(E).  (See  Figure  16). 


f.  Operational  Characteristics.  The  differences  in 
operational  characteristics  of  Architecture  III  and  Architec¬ 
ture  II  are  described  in  the  following  sub -paragraphs  in 
terms  of  traffic  flow,  security,  and  system  control. 
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(1)  Traffic  Flow.  One  major  difference  in  the 
traffic  flow  of  Architectures  II  and  III  is  the  splitting  of 
services  between  the  CSF  and  the  I-S/A  AMPE(E)  in  Architecture 
III. 

3 

(2)  Security.  Security  for  non-E  users  is 
provided  in  Architecture  III  as  it  is  in  Architecture  II. 

Security  for  EJ  users  is  provided  in  the  same  manner  as 
Architecture  II  except  that  the  BLACKER  elements  may  be 
located  at  different  places  in  the  network. 

(3)  System  Control.  System  control  considerations 
are  essentially  the  same  for  Architecture  III  as  for  Architecture 
II  except  that  an  additional  requirement  will  exist  for 
control  of  the  CSFs  and  performance  of  system  control  functions 
by  the  CSFs. 

4.  Summary .  The  basic  configuration,  nodal  element 
types,  and  functional  allocation  for  the  three  alternative 
architectures  are  summarized  in  Figure  21.  This  figure 
presents  a  simplified  representation  of  each  architecture. 

As  discussed  earlier  in  this  section,  these  three  alternatives 
represent  the  three  major  classes  of  architectures  (centralized, 
distributed  and  hybrid)  applicable  to  the  IAS  mid-term.  Each 
of  these  architectures  provides  the  required  mid-term  IAS 
services  and  functions  and  is  consistent  with  the  contraints 
and  anticipated  operating  environment  of  the  mid-term.  In 
addition,  each  of  these  alternative  architectures  represents 
an  evolutionary  departure  from  the  near-term  IAS  architecture 
described  in  Section  II. 

D.  Evaluation  of  Alternatives. 

1.  General .  To  determine  the  preferred  IAS  mid-term 
architecture,  the  three  alternative  architectures  described 
above  were  evaluated  with  respect  to  both  technical  and  cost 
factors.  This  evaluation  was  based  on  a  series  of  quantitative 
and  qualitative  technical  analyses  performed  in  support  of 
the  IAS  architecture  definition.  In  order  to  provide  a  high 
degree  of  confidence  in  the  final  results  of  the  evaluation, 
the  general  approach  to  alternative  evaluation  was  based  on 
the  following  guidelines  .• 

Evaluation  on  the  basis  of  comparative/relative 
performance  vice  absolute  performance  estimates 

Application  of  quantitative  analytic  techniques 
wherever  possible  and  appropriate 


Consideration  of  all  relevant  factors  in 
subjective/qualitative  analyses 

.  Careful  documentation  of  factors  considered  and 
basis  for  subjective  decision 

.  Thorough  review  of  analysis  methods  and  results 

.  Final  evaluation  based  on  preference/rank  order 
vice  measure  of  effectiveness 

The  eventual  performance  of  any  system  is  difficult  to 
measure  at  such  an  early  stage  of  architectural  definition; 
detailed  system  performance  requirements  based  on  future 
user  applications/needs  cannot  be  specified  until  later  in 
the  system  definition/design  cycle;  and  each  alternative 
archtecture  is  capable  of  meeting  the  anticipated  future 
performance  requirements  through  design  tradeoffs  within  the 
state-of-the-art;  therefore,  the  differences  between  alternative 
architectures  were,  in  many  cases,  measured  in  terms  of  the 
difficulty  or  complexity  of  meeting  performance  objectives 
in  given  areas  based  on  inherent  architecture  characteristics. 
Examples  of  such  characteristics  are:  (1)  the  number  of 
nodal  and  transmission  delays  that  must  be  encountered  from 
user  to  user/service  element;  (2)  the  number  of  different 
nodal  elements  contained  in  the  network  and  the  degree  of 
commonality  among  elements;  (3)  the  number  of  operations 
required  to  complete  a  message  transfer  including  inter¬ 
mediate  processing;  and  (4)  the  number  of  elements  available/ 
required  for  user  connection/service  access.  In  order  to 
facilitate  evaluation  of  the  alternative  architectures,  the 
results  of  these  studies  are  summarized  in  the  following 
paragraphs . 

2.  Evaluation  Criteria  and  Comparison.  Five  major 
evaluation  criteria  are  operational  effectiveness ,  flexibil¬ 
ity,  survivability /availability/supportability,  transition 
and  cost.  Within  each  criterion,  from  two  to  six  sub¬ 
criteria  were  considered.  Within  each  sub-criterion,  one  to 
sixteen  factors  and  sub- factors  were  evaluated.  On  the 
basis  of  the  technical  analyses  performed  as  part  of  the 
evaluation  process,  the  relative  advantages  and  disadvantages 
of  each  alternative  were  identified.  The  following  sub- 
paragraphs  define  each  major  criterion  and  present  the 
results  of  the  evaluation  process. 

a.  Operational  Effectiveness. 

(1)  Definition.  This  criterion  addresses  the 
relative  efficiency  and  effectiveness  of  an  architecture  for 
providing  the  required  functional  capability.  The  sub-criteria 


used  in  chis  category  were  speed  of  service,  user  interfaces, 
transmission  overhead,  system  motivated  functions,  security 
and  adaptability  to  overseas.  Lower  level  factors  and  sub¬ 
factors  used  in  the  sub-criteria  were:  speed  of  service  by 
traffic  type  (e.g.,  interactive,  query /response,  key  distri¬ 
bution,  mailbox);  interface  complexity  for  access  to  and 
interaction  with  network  services;  transmission  overhead  by 
network  function  (e.g.,  addressing,  normal  routing,  CARP 
routing,  flow  control,  error  control,  system  control); 
complexity  of  system  motivated  functions  (e.g.,  system 
control,  accountability);  ability  to  meet  security  objectives 
(e.g.,  end-to-end  encryption,  minimum  number  of  "RED"  elements 
required,  future  security  growth  capability) ;  ability  to 
support  mobile  terminals,  ability  to  use  mobile/transportable 
elements  based  on  element  size  and  potential  user  impact; 
risk  of  overseas  deployment  associated  with  PSN,  CSF,  I-S/A 
AMPE(E) ;  size  of  CONUS/  overseas  trunks;  and  survivability. 

(2)  Technical  Factors  Comparison.  Alternative  I 
with  its  CSF  and  direct  connection  of  subscribers  and  I-S/A 
AMPEs  to  PSNs  was  determined  to  provide  the  best  potential 
for  performance  in  this  evaluation  category.  Due  to  its 
less  complex  structure  and  direct  user  access.  Alternative  I 
could  potentially  provide  a  slight  advantage  over  the  other 
two  alternatives  in  the  areas  of  service  delivery  time  and 
application  to  overseas  operating  environments.  However, 
each  of  the  alternative  architectures  is  capable  of  meeting 
the  functional  performance  requirements  and  the  anticipated 
technical  performance  requirements  of  the  mid-term  IAS.  It 
should  also  be  recognized  that  Alternative  II  and  Alternative 
III  provide  a  high  degree  of  flexibility  in  the  access  area 
through  dual  connection  of  the  I-S/A  AMPE  as  well  as  through 
alternative  connections  for  both  narrative/record  and  computer 
data  subscribers.  The  system  design  for  the  preferred 
architecture  can,  therefore,  take  advantage  of  these  capabil¬ 
ities  to  provide  optimum  service  access  for  most  users.  As 
a  result  of  system  design  optimization,  the  operational 
effectiveness  of  the  Alternative  II  architecture  will  approach 
the  optimum  available  performance. 

b.  Flexibility. 

(1)  Definition:  This  criterion  measures  the 
ability  of  an  architecture  to  accommodate  change.  Two  sub- 
criteria  were  defined  in  this  category--adaptability  and 
expandability.  Adaptability  refers  to  the  ability  of  an 
architecture  to  accommodate  changes  in  the  demand  or  utili¬ 
zation  of  its  planned  capabilities.  Expandability  measures 
the  ability  of  the  architecture  to  accommodate  additional 
requirements.  Adaptability  factors  include  the  Impact  of 
changes  in:  traffic  types  (bulk  versus  narrative/record. 


secure  versus  non-secure) .external  interfaces ,  network 
services,  subscriber/  traffic  distribution  (PSN  versus  I-S/A 
AMPE  connected,  geographic  distribution,  local  versus  remote, 
ratio  of  AUTODIN  I/AUTODIN  II  subscribers).  Expandability 
factors  include  the  potential  impact  of  additional  subscribers 
(number,  types),  protocols  (user/user,  user/service,  link), 
services,  control  functions,  traffic,  and  external  interfaces. 


(2)  Technical  Factors  Comparison.  Alternative 

I  is  potentially  less  sensitive  to  changes  in  the  day-to-day 
network  operation  within  the  original  system  design  limits 

due  to  its  relatively  flat  structure  (no  access  area  hierarchy) 
and  its  potential  for  load  sharing  of  processing  within  a 
single  service  element  (i.e.,  the  CSF) .  However,  Alternatives 

II  and  III  were  found  to  be  significantly  more  flexible  and 
less  sensitive  to  major  changes  in  requirements  and  future 
growth  because  of  the  greater  number  of  connection/ configuration 
options  available  within  these  architectures.  In  addition, 

it  should  be  noted  that  the  implementation  of  the  new  IAS 
network  elements  can  potentially  have  as  much  impact  on 
system  flexibility  as  the  architecture  selected.  For  example, 
it  is  anticipated  that  the  1-S/A  AMPE  and  the  I-S/A  AMPE(E) 
will  be  implemented  based  on  a  multiprocessor  architecture. 

This  will  permit  the  high  degree  of  expandability  required 
to  permit  graceful  evolution  of  the  I-S/A  AMPE  throughout  the 
mid-term  and  protect  against  saturation  of  the  I-S/A  AMPE 
processing  capability. 


c.  Survivability/Availability/Maintainability. 

(1)  Definition.  This  criterion  considers  the 
inherent  ability  of  an  architecture  to  provide  the  required 
service  in  both  normal  and  hostile  operating  environments. 

The  subcriteria  defined  in  this  category  include:  the 
effect  of  nodal/link  failures  on  system  operation,  the 
ability  of  the  architecture  to  protect  against  nodal/link 
failures,  the  ability  of  the  architecture  to  recover  from 
failures  and  the  maintainability  of  the  architecture.  Lower 
level  factors  considered  within  this  criterion  include  the 
potential  loss  of  service  and  access,  the  complexity  of  CARP 
(source/network) ,  dual  homing  flexibility,  ability  to  support 
redundant  nodes,  number  of  elements  requiring  support  and 
degree  of  commonality  among  elements. 

(2)  Technical  Factors  Comparison.  Alternative 
II  offers  a  high  degree  of  hardware /software  commonality  and 
therefore  minimizes  the  availability/maintainability  requirements 
of  the  network.  In  addition.  Alternative  II  offers  improved 
survivability  through  dual  connection  of  the  I-S/A  AMPEs  and 
increased  independence  of  the  I-S/A  AMPEs  for  message  transfer 
operations . 
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d.  Transition. 


(1)  Definition.  This  criterion  considers  the 
ability  of  an  architecture  to  evolve  from  the  near-term  to 
and  beyond  the  specific  mid- term  architecture.  Sub-criteria 
identified  within  this  area  were  technical  risk,  user  impact, 
ease  of  implementation,  and  potential  for  continued  evolution. 
Lower  level  factors  include  hardware  and  software  development 
risks,  continuity/disruption  of  service,  availability  of 
requred  elements,  extent  of  modifications  required  to 
existing  elements,  consistency  with  far-term  architectural 
objectives  (e.g.,  satellite  broadcast  backbone,  integrated 
voice  and  data). 

(2)  Technical  Factors  Comparison.  Alternative 
II  represents  the  best  architectural  basis  for  transition 
from  the  near-term  to  the  mid-term  IAS  network.  In  addition. 
Architecture  II  offers  the  best  architecture  for  continued 
evolution  through  the  far- term  toward  the  DCS  objectives  of 
both  satellite  broadcast  backbone  utilization  and  integration 
of  voice  and  data  networks.  In  general.  Alternative  II 
represents  the  least  risk  and  difficulty  for  transition 
because  only  a  single  network  service  element  must  be  imple¬ 
mented  (i.e.,  I-S/A  AMPE(E) ) .  In  addition,  development/ 
implementation  risk  is  further  reduced  because  the  I-S/A 
AMPE(E)  is  derived  from  the  currently  planned  I-S/A  AMPE 
program.  It  should  be  noted  that  the  risk  assessment 
performed  as  part  of  the  evaluation  was  based  upon  the 
overall  IAS  implementation  strategy  and  technology  trends 
defined  in  the  IASA  Report  (Part  1)  (i.e.,  common  family  of 
hardware /transportable  software,  multi-processor  nodal 
architecture). 

e.  Costs. 

(1)  Definition.  This  criterion  measures  the 
potential  of  each  architecture  for  reducing  the  cost  of 
ownership  and  operation  of  the  mid-term  IAS.  Major  cost 
elements  considered  as  sub- criteria  within  this  category  are 
transmission  costs,  nodal  element  acquisition  costs,  and 
operation  and  maintenance  cost.  Lower  level  cost  factors 
include  initial  and  recurring  costs  associated  with  backbone 
trunks  and  access  area  conanunications  facilities,  hardware 
and  software  investment  costs,  and  personnel  support  and 
training  costs. 

(2)  Cost  Factors  Comparison.  As  part  of  the 
alternative  evaluation  process,  a  comparative  cost  analysis 
was  performed  and  is  provided  in  Appendix  3.  This  analysis 
identified  all  major  cost  components  of  the  mid-term  IAS  and 
evaluated  those  factors  which  were  found  to  be  dependent 


upon  network  architecture.  The  results  of  the  analysis 
indicated  that  when  each  of  the  alternative  factors  were 
compared  no  overriding  preference  for  a  preferred  architecture 
was  apparent.  However,  the  relative  weight  of  each  cost 
factor  should  be  considered  when  viewing  even  a  relative  low 
percentage  of  differences  (e.g.,  operation  and  maintenance 
costs  point  to  Alternative  II  with  approximately  37,  savings 
over  the  other  alternatives),  which  is  used  as  a  consideration 
in  selecting  the  preferred  architecture. 

f.  Sunmary.  Based  upon  the  results  of  the  evaluation 
process  the  preferred  architecture  for  the  mid-term  IAS  will 
be  based  upon  Alternative  II.  This  alternative  was  determined 
to  be  preferred  to  each  of  the  other  alternatives  in  three 
of  the  five  major  evaluation  criteria.  In  addition,  Alternative 
II  was  evaluated  to  be  preferred  in  the  two  technical  criteria 
which  are  considered  the  most  important  for  the  mid-term 
IAS —  transition  and  survivability/availability/supportability . 

A  principal  characteristic  of  this  architecture  which  led  to 
its  selection  is  the  consolidation/integration  of  network 
and  user  motivated  functions  into  a  single  service  element 
based  upon  the  currently  planned  Inter-Service/Agency  AMPE 
Program.  This  consolidation/integration  provides  significant 
potential  benefits  in  both  cost  and  performance  and  contributes 
materially  to  the  ease  of  transition  from  near-term  to  the 
mid-term  network  architecture. 

3.  Comparison  of  Preferred  Alternative  with  the  Baseline 
Projected  to  1988. 

a.  Definition.  In  order  to  gain  insight  into  the 
potential  advantage  of  implementing  the  preferred.  Alternative 
II,  mid-term  IAS  architecture,  a  comparison  is  made  of  the 
preferred  architecture  with  the  1983  baseline  architecture 
projected  to  a  probable  1988  configuration.  The  baseline 
architecture  used  in  this  analysis  would  incorporate  only 
those  changes  and  upgrades  required  to  maintain  current 
system  capabilities.  Based  on  current  DoD  policy,  the  1983 
baseline  architecture  includes  provision  for  replacement  of 
existing  AMPEs  with  the  I-S/A  AMPE.  However,  because  these 
new  AMPE  systems  would  not  have  the  additional  capability  of 
the  I-S/A  AMPE(E)  used  in  the  preferred  architecture,  it  is 
unrealistic  to  assume  that  consolidation  could  be  achieved 
in  the  projected  1983  baseline  architecture.  Therefore,  the 
number  of  AMPEs  projected  for  the  1988  configuration  was 
derived  from  current  and  planned  AMPE  requirements  (see 
Appendix  2).  In  addition,  technical  factors  of  the  projected 
1988  architecture  ere  presented  in  Appendix  3. 


b.  Technical  Factors  Comparison.  This  analysis 
includes  an  evaluation  of  nodal  element  acquisition  costs 
and  personnel  requirements  for  the  preferred  architecture 
and  the  1983  baseline  projected  to  1988. 

(1)  Modal  Element  Acquisition.  This  cost 
comparison  indicated  that  a  total  estimated  acquisition  cost 
of  the  preferred  architecture  is  approximately  ( DELETED ) 
greater  than  the  projected  baseline.  (See  Table  20,  Appendix 


(2)  Personnel  requirements.  The  manning  estimates 
for  proposed  new  IAS  elements  were  obtained  using  the  available 
ASC  and  AMPE  information  as  a  baseline.  As  previously 
stated,  the  cost  comparison  data  between  alternatives  was 
not  a  deciding  factor  for  selection  of  a  preferred  alternative. 
However,  the  comparison  of  operation  and  maintenance  personnel 
costs  for  the  preferred  architecture  versus  the  baseline 
projected  to  1988  indicates  a  potential  savings  of  about 
2000  personnel  which  equates  to  $39  million  per  year. 

(See  Table  7,  page  95).  The  magnitude  of  the  potential 
savings  indicated'  by  this  analysis  demonstrate  an  opportunity 
for  a  reduction  of  total  AUTODIN  operation  and  maintenance 
costs  through  the  implementation  of  the  preferred  mid-term 
architecture. 

E.  Summary .  The  preferred  architecture  for  the  mid-term 
Integrated  AUTODIN  System  (IAS)  is  based  on  the  selection  of 
Alternative  II,  which  represents  a  distributed  architecture 
where  services  are  provided  from  a  common  access  area  element. 
This  architecture  meets  all  anticipated  mid-term  IAS  operational 
requirements  and  provides  a  substantial  improvement  over  the 
near-term.  The  preferred  architecture  provides  significant 
advantages  over  the  baseline  (1983)  projected  to  1988  in 
terms  of  transition  capabilities  (both  for  the  mid-term  and 
beyond),  survivability/availability  and  costs. 

1.  Elements .  The  preferred  mid-term  IAS  architecture 
will  use  a  combination  of  existing  and  newly  developed 
network  elements.  The  major  elements  of  the  architecture 
and  their  application/role  in  the  architecture  are: 

a.  Packet  Switch  Node  (PSN) .  The  AUTODIN  II  PSN 
should  not  require  any  modifications. 

b.  Inter- Service/Agency  AMPE  (I-S/AAMPE).  The  I- 
S/A  AMPE  is  used  in  the  preferred  architecture  as  both  a 
local  message  processing  service  element  an  a  communication 
network  front-end. 


c.  Inter- Service/Agency  AMPE  Enhanced  (I-S/A  AMPE(E)). 
In  the  preferred  architecture,  the  I-S/A  AMPE(E)  will  fill 

two  distinct  roles.  First,  it  will  function  as  a  normal  I- 
S/A  AMPE  for  its  locally  connected  subscribers.  In  this 
role  it  will  provide  local  terminal  support  and  message 
processing  functions  and  act  as  the  network  front-end. 

Secondly,  the  I-S/A  AMPE(E)  will  serve  as  a  network  service 
element  and  it  will  provide  the  basis  for  network  expansion 
through  upgrade  of  installed  I-S/A  AMPEs  to  enhanced  I-S/A 
AMPE(E)  configurations.  Based  on  a  modular,  transportable 
software  development  approach,  it  is  anticipated  that  any  I- 
S/A  AMPEs  can  be  converted  to  enhanced  status  after  in¬ 
stallation.  The  I-S/A  AMPE  family  of  equipments  is,  therefore 
the  key  to  both  implementation  and  continued  evolution/growth 
of  the  IAS  network. 

d.  Subscriber  Terminals.  The  mid-term  IAS  will  have 
to  support  all  existing  types  of  AUTODIN  I  and  planned 
AUTODIN  II  terminals.  It  is  also  expected  that  terminals 
with  additional  capabilities  will  be  introduced  in  the  mid¬ 
term  as  part  of  the  common  family  of  AUTODIN  terminals . 
Although  increased  capability  in  some  terminals  will  not 
relieve  the  network  of  supporting  the  remainder  of  less 
capable  terminals,  it  can  reduce  the  processing  load  on  the 
network  and  reduce  the  dependence  of  the  terminals  on  other 
network  elements. 

2.  Benefits .  The  preferred  architecture  is  consistent 
with  the  mid-term  IAS  objective  and  is  capable  of  providing 
all  of  the  required  services  and  functions  as  defined  in 
Section  II  of  this  report.  In  summary,  the  preferred  archi¬ 
tecture  offers : 

a.  Significant  potential  benefits  to  the  entire  DoD 
AUTODIN  community. 

(1)  Reduced  Cost  of  Ownership.  The  preferred 
architecture  offers  significant  opportunity  for  reduction  in 
O&M  cost  through  standardization  of  Service/Agency  message 
processing  and  communications  hardware,  software  and  operating 
procedures.  Additional  savings  will  result  from  consolidation 
of  network  service  elements  and  local  user  message  processing 
elements  in  the  access  region.  Finally,  a  major  cost  savings 
will  be  possible  through  personnel  reductions  as  a  result  of 
consolidation  of  AMPE  sites  into  joint  Service/Agency  multi¬ 
user  I-S/A  AMPE  configurations. 

(2)  Enhanced  Survfvability .  The  preferred 
architecture  will  provide  improved  access  reliability  for 
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users  through  multiple  interconnection  of  network  eccese 
nodes  (I-S/A  AMPE  and  I-S/A  AMPE(E)) .  In  addition,  since 
user  access  nodes  are  not  dependent  on  higher  level  elements 
for  normal  message  traffic,  the  loss  of  a  single  network 
element  will  have  little  effect  on  total  system  operation. 

In  fact,  the  preferred  architecture  should  provide  graceful 
degradation  of  service  in  the  face  of  network  node/link 
losses. 

(3)  Improved  Performance.  The  preferred 
architecture  will  permit  the  introduction  of  significant  new 
telecommunication  services  and  features.  In  addition,  the 
improved  access  arrangements  and  distribution  of  services 
nodes  throughout  the  access  area,  will  permit  improved  spee.l 
of  service  and  overall  increased  network  responsiveness  to 
user  needs.  Furthermore,  the  flexibility  inherent  in  the 
preferred  architecture  will  allow  the  mid-term  AUTODIN 
system  to  accommodate  many  unique  user  requirements  without 
penalty  to  other  users. 

(4)  Evolutionary  Transition.  The  preferred 
architecture  can  be  implemented  in  a  smooth  evolutionary 
process  from  the  1983  near-term  architecture.  In  addition, 
the  preferred  architecture  provides  a  framework  for  continued 
evolutionary  development  of  the  IAS  through  1988  and  beyond. 

b.  Among  the  potential  benefits  of  the  preferred 
architecture,  the  most  important  may  well  be  its  ability  to 
evolve  in  a  smooth  and  orderly  process  from  the  current 
AUTODIN.  In  order  to  demonstrate  the  feasibility  of  this 
transition  process,  the  final  Section  of  this  report  presents 
a  transition  plan  for  the  implement at ion  of  the  preferred 
architecture  in  the  mid-term  (1984-1988). 


SECTION  IV 
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SECTION  IV 


TRANSITION  STRATEGY 


A.  Purpose.  The  purpose  of  this  section  is  to  demonstrate 
the  feasibility  of  achieving  the  mid-term  IAS  in  an  evolu- 
ionary  manner  by  defining  a  transition  approach  for  the  mid¬ 
term.  The  near-term  IAS  serves  as  a  point  of  departure  to 
the  mid-term  transition  approach  by  reviewing  and  updating 
near-term  activities  and  milestones.  A  transition  strategy 
is  postulated,  with  alternative  approaches  where  applicable, 
for  evolving  from  the  near-term  (1978-1983)  to  the  mid-term 
(1984-1988).  Finally,  the  sequence  of  events,  milestones, 
and  interdependence  of  activities  for  the  transition  approach 
are  presented. 

B.  Achieving  Evolutionary  Transition. 

3 

1.  General.  In  accordance  with  ASD/C  I  direction,  the 
IAS  will  evolve  in  a  deliberate  and  continuous  fashion  from 
today's  communications  to  the  more  sophisticated  communica¬ 
tions  of  the  future.  This  guidance  precludes  the  possibility 
of  any  single  "turnkey"  type  of  operation  where  one  system 
is  replaced  by  another  at  some  pre-established  date.  Hence, 
the  need  for  a  smooth  transition  over  the  next  decade  becomes 
paramount  to  the  IAS  architectural  strategy.  Continuity  of 
service  and  user  transparency  emerge  as  important  transi¬ 
tional  considerations.  The  incremental  addition  of  new 
network  elements  (e.g.,  PSNs  and  I-S/A  AMPEs)  and  the  concomi¬ 
tant  phasing  out  of  obsolete  equipment  (e.g.,  ASCs  and 
AMPEs)  will  characterize  the  evolution.  The  transition  must 
be  performed  within  the  framework  of  a  circa  1990  IAS,  i.e., 
the  employment  of  equipment,  techniques,  and  philosophies 
should  be  consistent  with  the  full  range  of  potential  circa 
1990  architectures.  These  considerations  and  others  have 
been  factored  into  a  general  approach  to  achieving  evolu¬ 
tionary  transition. 

In  the  IASA  Report  (Part  1) ,  transition  strategies  were 
identified  for  two  markedly  different,  but  feasible  circa 
1990  architectures:  one  based  on  terrestrial  switching,  the 
other  based  on  broadcast  satellite  use.  It  was  assumed  that 
the  architecture  selected  for  circa  1990  would  lie  somewhere 
between  these  extremes.  Since  each  of  the  alternatives 
considered,  although  differing  widely  in  the  backbone  architec 
ture,  proceeds  initially  from  the  present  (1979)  architecture 
in  the  same  manner,  it  was  concluded  that  the  chosen  architec¬ 
ture  would  require  the  same  sequence  of  events  in  the  near- 
term.  Consequently,  a  single  near-term  transition  approach 


was  developed.  In  order  to  ensure  the  continued  evolution  of 
the  IAS  beyond  the  near-term,  a  transition  approach  for  the 
mid-term  must  be  defined. 

2.  Near-Term  IAS .  The  near-term  IAS,  to  be  implemented 
through  1983 ,  is  depicted  in  Figure  22.  Subsequent  para¬ 
graphs  describe  the  network  elements,  functional  allocation, 
and  transitional  approach  for  achieving  the  near-term  IAS. 

a.  Network  Elements.  In  the  near-term,  the  IAS 
will  consist  of  a  set  of  elements  that  satisfy  validated 
service  requirements  with  little,  if  any,  technical  risk. 

(1)  AUTODIN  Switching  Center  (ASC) .  By  1983, 
eleven  to  fifteen  ASCs  should  be  in  operation  (six  government 
owned  overseas,  one  leased  in  Hawaii,  and  four  to  eight 
leased  in  CONUS) .  Overseas  ASCs  should  either  be  trunked  to 
CONUS  ASCs  or  receive  trunking  via  PSNs.  CONUS  ASCs  should 
receive  their  trunking  through  the  PSNs.  Functionally,  the 
ASC  will  be  essentially  unchanged  from  what  exists  today. 

(See  IASA  Report  (Part  1)  for  further  discussion  on  factors 
affecting  closures  of  ASCs.) 

(2)  Packet  Switch  Node  (PSN) .  It  is  expected 
that  eleven  PSNs  (three  overseas  and  eight  in  CONUS)  should 
be  in  place  and  operational  by  1983.  The  CONUS  PSNs  may  be 
collocated  with  the  remaining  CONUS  ASCs  and  interface  via 

a  Mode  VI  serial  communications  interface  capable  of  multiple 
virtual  connections.  The  PSNs  will  be  interconnected  by 
multiple  packet  trunks  operating  at  speeds  from  9.6  to  56 
kbps  derived  from  common  carrier  facilities.  In  addition  to 
providing  packet  switching  service  to  AUTODIN  II  subscribers, 
the  PSN  will  terminate  AUTODIN  I,  Mode  I  subscribers  e.g., 
AMPEs.  All  traffic  so  received  will  be  transferred  to  a 
home  ASC  for  normal  AUTODIN  I  processing. 

(3)  Automated  Message  Processing  Exchange 
(AMPE) .  Service /Agency  projections  indicate  that  the  number 
of  AMPEs  in  the  near-term  IAS  should  be  about  109.  AMPE 
plans  are  being  evaluated  on  a  case-by-case  basis.  AMPEs 
will  be  terminated  on  either  PSNs  or  ASCs  using  AUTODIN  I, 
Mode  I  protocol.  For  availability  and  backup  purposes,  some 
AMPEs  will  be  dual  homed,  i.e.,  connected  to  either  two 
PSNs,  two  ASCs,  or  a  PSN  and  an  ASC. 

(a)  The  following  AMPE  types  will  opera¬ 
tional  in  the  near-term  IAS:  Army’s  AMME,  Navy's  LDMX  and 
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NAVCOMPARS,  Air  Force's  AFAMPE,  NSA's  STREAMLINER  and  DLA's 
AMPE.  All  of  the  AMPEs  to  varying  degrees  provide  AUTODIN 
system  functions,  Telecommunications  Center  functions,  and 
Customer  Assistance  functions.  Reference  is  made  to  the 
IASA  Report  (Part  1)  for  details  on  these  functions. 

(b)  The  functional  composition  of  the 
AMPEs  varies  by  Service/Agency  as  each  AMPE  was  designed  and 
developed  independently  to  provide  mission-oriented  functions 
and  features.  Consequently,  it  is  difficult  for  each  AMPE 
to  be  used  by  subscribers  outside  the  intended  community  of 
interest.  AMPE  Functional  Comparison  studies  have  addressed 
this  problem  and  concluded  that  there  is  a  large  amount  of 
functional  similarity  among  the  AMME,  LDMX,  NAVCOMPARS,  and 
AFAMPE  systems.  As  a  result,  the  IASA  Report  (Part  1)  recom¬ 
mended  the  I-S/A  AMPE  program  replace  the  current  Service/Agency 
AMPE  programs  by  1983. 

(4)  I-S/A  AMPE.  In  the  near-term,  the  I-S/A 
AMPE  program  will  provide  new  AMPE  systems  for  Special 
Intelligence  as  well  as  General  Service  requirements  and 
should  be  available  by  1982.  The  near-term  element  of  the 
program  is  defined  as  Phase  I,  by  which  we  will  define  and 
develop  standard  AMPE  functions  leading  to  procurement  based 
upon  joint  functional  specifications  and  release  a  Request 
for  Proposals  during  the  1980s,  with  fielding  during  fiscal 
year  1982.  Reference  is  made  to  Appendix  2  for  additional 
detail  on  implementation  of  this  Phase  I  element. 

(5)  Subscriber  Terminals.  The  near-term  will 
accommodate  a  wide  variety  of  subscriber  terminals,  ranging 
from  Model-28  Teletypewriters  to  sophisticated  software 
programmable  devices  such  as  Standard  Remote  Terminals 
(SRTs)  and  ADP  hosts.  Depending  on  the  service  needs  of  the 
subscriber,  subscriber  terminals  will  be  terminated  on 
AMPEs,  ASCs,  or  PSNs.  The  various  termination  alternatives 
available  to  a  subscriber  are  shown  in  Table  8.  While  it 
would  appear  that  the  various  programmable  devices  could  be 
reprogrammed  to  interface  directly  with  a  PSN,  each  device 
should  be  considered  on  an  individual  basis  to  determine  the 
desirability,  feasibility  and  cost-effectiveness  of  doing 
so. 


b.  Transition  Strategy.  The  strategy  adopted  for 
transitioning  to  the  near-term  IAS  is  characterized  by  the 
sequence  of  events,  target  dates,  and  the  interdependencies 
of  events.  Table  9  lists  the  required  activities  and  their 
associated  target  dates  in  chronological  order.  Figure  23 
presents  the  transition  activities  as  a  milestone  chart  to 
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TABLE  8 


NEAR-TERM  IAS  TERMINATIONS 


TERMINATING  DEVICE 

Network 

Element 

AMPE 

ASC 

PSN 

AMPE 

no 

yes 

yes* 

AUTOOIN  I  Mode  I 

Terminal 

■ 

yes 

yes 

yes* 

AUTODIN  I  MODES  II  &  V 
Terminal 

yes 

yes 

no 

AUTODIN  II 

Terminal 

no 

no 

yes 

Host 

(AUTODIN  II) 

no 

no 

yes 

♦Terminated  on  a  PSN  but  homed  to  an  ASC. 
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TABLE  9 

NEAR-TERM  IAS  TRANSITION  PLAN 


Activity 

CY  Target  Date 

a. 

Field  AMPEs 

In  Progress 

b. 

Overseas  (0/S)  ASC  Memory  Upgrade 

1978 

c. 

CONUS  ASC  Tape  Replacement  by  Disc 

1978 

d. 

Start  Fielding  SRTs 

1978 

e. 

Close  One  PAC  Area  ASC  (Buckner) 

1978 

f. 

Close  Second  PAC  Area  ASC  (Clark) 

1979 

9- 

Select  LMD  for  I-S/A  AMPE 

1979 

h. 

IOC  AUTODIN  II  Phase  I  (3  PSNs) 

1979 

i . 

0/S  ASC  Tape,  Card  Reader  and  Printer 

Replacement;  Upgrade  of  Patch  and  Test  Facilities 

1980 

j. 

Complete  Fielding  AUTODIN  II  Phase  I  (4  PSNs) 

1980 

k. 

Start  Phase  Out  CONUS  ASCs;  Rehome 

Affected  Subscribers 

1981 

1. 

Field  Initial  0/S  AUTODIN  II  PSNs 

1981 

m. 

Start  AUTODIN  II  CONUS  Expansion 

1981 

n. 

Complete  Fielding  AMPEs 

1982 

0. 

Start  Fielding  Basic  I-S/A  AMPE  (Phase  I) 

1982 

P* 

Complete  AUTODIN  II  CONUS  Expansion 

1983 

q* 

Complete  Phase  Out  (up  to  Four)  CONUS  ASCs 

1983 

r. 

Near-Term  IAS  Architecture  Achieved 

1983 
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MAJOR  MILESTONES 


aid  in  visualizing  their  interdependencies.  The  transitional 
approach  is  consistent  with  guidance  to  achieve  the  mature 
circa  1990  IAS  in  an  evolutionary  manner  for  the  range  of 
alternative  architectures  being  considered  for  that  time 
period. 

3.  Mid-Term  IAS.  The  mid-term  (1984-1988)  IAS  will 
evolve  gracefully  from  the  near-term  system  and  will  be 
consistent  with  the  full  complement  of  potential  circa  1990 
architectures .  Figure  24  depicts  the  mid-term  system  as  it 
will  appear  circa  1988.  In  contrast  with  the  near-term  IAS, 
which  is  constrained  by  the  use  of  existing  technology  and 
equipment,  the  mid-term  system  begins  to  exploit  the  advan¬ 
tages  of  the  state-of-the-art  in  communications.  Accordingly 
the  mid-term  transition  strategy  is  driven  by  the  following 
architectural  objectives: 

Replace  equipment  as  it  becomes  outdated  with  new 
or  augmented  standardized  network  elements  (e.g., 
replace  AMPES  with  I-S/A  AMPEs) 

Preserve  continuity  of  existing  network  services 
Provide  for  needed  new  services 

.  Develop  and  field  new  functional  capabilities 

(e.g.,  end-to-end  encryption  with  key  distribution 
centers) 

Reduce  O&M  costs 

.  Expand  AUTODIN  II  to  provide  a  worldwide  data 
backbone 


Enhance  system  survivability 

Enhance  tactical  and  allied  forces  interoperability 

With  respect  to  these  objectives,  there  are  several  transition 
issues  that  need  resolution.  These  include: 

User  transparency 

Functional  allocation/reallocation 

-  transfer  of  functional  responsibility  (e.g., 

ASC  to  I-S/A  AMPE(E) ) 

-  field  testing  of  new  functional  capabilities 
for  user  acceptance 


i 

Mrl 

m 


MID-TERM  IAS  ARCHITECTURE 
FIGURE  24 


Replacement/integration  strategy 


-  incremental  addition  of  new  network  elements 

-  cutover  strategies 

-  phasing  out  of  obsolete  or  non-cost-effective 
equipment 

-  rehoming  affected  subscribers 

-  impact  on  remaining  network  elements 

Overseas  implications. 

These  issues  and  objectives  have  been  factored  into  an 
overall  IAS  system  transition  strategy  which  can  in  turn  be 
subdivided  into  more  detailed  lower  level  (network  element) 
transition  strategies.  The  intent  of  the  subsequent  dis¬ 
cussions  is  to  illustrate  the  overall  mid-term  transition 
strategy  by  identifying  transition  alternatives  at  each 
level . 


a.  Network  Elements.  In  addition  to  the  near- term 
network  elements,  which  will  exist  into  and  in  some  in¬ 
stances  through  the  mid-term,  a  number  of  new  network  ele¬ 
ments  should  be  implemented  in  the  mid-term. 

(1)  Inter- Service/Agency  AMPE  Enhanced  (I-S/A 
AMPE(E)).  As  stated  previously  the  I-S/A  AMPE  will  be  used 
to  satisfy  all  requirements  for  new  or  replacement  AMPEs . 

An  enhanced  version  of  this  network  element,  the  I-S/A 
AMPE(E),  in  addition  to  providing  AMPE  functions  and  services, 
will  assume  the  functional  role  of  the  near-term  ASC  and 
will  provide  network  services  currently  outside  the  scope  of 
the  near-term  system. 

(2)  Central  Service  Facility  (Contingency 
Option).  Although  the  preferred  mid-term  IAS  architecture 
does  not  include  this  element,  the  CSF  represents  a  potential 
system  level  transition  option.  This  option  will  be  exercised 
only  in  the  event  that  new  requirements  emerge  that  cannot 

be  accommodated  within  the  I-S/A  AMPE(E)  program. 

(3)  Common  Family  of  Terminals  (CFT) .  A  new 
generation  of  subscriber  equipment  will  be  introduced  in  the 
mid-term  time  frame. 

(4)  Security  Components.  An  end-to-end  encryption 
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(EJ)  capability  derived  from  the  BLACKER  hardware  and 
software  developments  will  be  introduced  in  the  mid-term 
time  frame. 

b.  Transition  Strategy.  Relative  to  the  mid-term 
network  elements,  transition  planning  focuses  on  meeting  the 
following  specific  transition  objectives: 

Implementation  of  the  I-S/A  AMPE  Program 

Expansion  of  the  PSN  backbone 

.  Introduction  of  the  CFT 

3 

Integration  of  E  security  into  the  operational 
network . 

The  transition  issues  relative  to  each  of  these  objectives 
are  discussed  in  detail  in  the  remainder  of  this  section. 

(1)  Implementation  of  I-S/A  AMPE  Program. 

(a)  Development  Approach.  The  I-S/A  AMPE 
program  is  based  on  the  development  of  a  common  standardized 
set  of  hardware  and  software  modules.  The  modular  approach 
of  this  program  coupled  with  the  use  of  a  High  Order  Language 
(HOL)  for  software  development  should  alleviate  critical 
manpower  and  unique  software  support  requirements  that 
characterized  the  independent  AMPE  programs.  Accordingly, 
this  approach  should  result  in  reduced  maintenance  costs  and 
greater  flexibility  in  sizing  and  configuring  the  access 
area.  Also  inherent  to  this  approach  is  the  potential  for 
providing  specific  functional  modules  locally  where  require  ’. 

(b)  I-S/A  AMPE  Roles.  The  I-S/A  AMPE 
program  will  fill  three  distinct  roles  in  the  mid-term  IAS: 

(1)  replacement  of  AMPEs ;  (2)  replacement  of  ASC s ;  and  (3) 
provision  of  new  IAS  service. 

The  I-S/A  AMPE  program  implementation  approach  reflects 
these  three  distinct  roles.  Accordingly,  the  following 
paragraphs  present  the  transition  issues  relevant  to  the  I- 
S/A  AMPE  in  each  of  its  projected  roles. 

(c)  AMPE  Replacement.  Each  I-S/A  AMPE 
implementation,  enhanced  or  otherwise,  will  provide  certain 
basic  capabilities  that  are  currently  allocated  to  the  AMPE, 
e.g.,  journaling,  retrieval,  intercept,  PLA/RI  conversion, 
format  and  code  conversion,  and  terminal  interface.  As  a 
minimum,  an  I-S/A  AMPE  will  function  as  an  AMPE  replacement. 
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The  precise  configuration  of  an  I-S/A  AMPE  will  vary  by 
location,  but  will  be  based  on  the  common  family  of  hardware/ 
software  modules.  Unique  functions  will  be  accommodated  on 
an  "as  required"  basis. 

The  lack  of  AMPE  standardization  makes  it  difficult  for  a 
subscriber  outside  the  intended  community  of  interest  to  use 
an  AMPE.  The  I-S/A  AMPE,  however,  will  provide  service  to 
all  Service/Agency  users.  Furthermore,  R/Y  consolidation 
will  be  achieved  in  this  network  element.  Consequently,  as 
the  IAS  evolves,  it  is  anticipated  that  the  replacement  of 
AMPEs  with  I-S/A  AMPEs  will  lead  to  consolidation  of  AMPE 
sites  and  an  accompanying  reduction  in  maintenance  cost. 

(See  Appendices  2  and  3  for  further  discussion) . 

The  target  date  for  the  first  operational  I-S/A  AMPE  (Phase  I) 
1982.  Subsequent  to  that  milestone  all  AMPE  implementations, 
new  or  replacement,  will  be  I-S/A  AMPEs.  Furthermore,  any 
AMPEs  scheduled  to  be  replaced  in  the  six  month  period 
immediately  preceding  introduction  of  the  I-S/A  AMPE  should 
be  delayed  so  that  they  can  be  replaced  by  an  I-S/A  AMPE. 

By  1990  all  current  AMPEs  will  be  replaced  by  the  I-S/A 
AMPE. 

The  actual  AMPE  replacement  strategy  and  total  I-S/A  AMPE 
requirements  will  be  defined  by  DCA  in  coordination  with 
potential  Service/Agency  users.  Nevertheless,  certain 
characteristics  of  the  transition  can  be  stated.  These 
relate  to  the  transition  issues  of:  (1)  cutover;  (2)  AMPE 
Replacement  Strategy;  (3)  survivability /Availability ;  (4) 
overseas  Implications;  and  (5)  support  Requirements.  These 
transition  issues  are  discussed  in  the  following  paragraphs 

1L.  Cutover  to  I-S/A  AMPE.  Since 
continuity  of  service  and  user  transparency  are  primary 
transition  objectives,  the  replacement  of  an  AMPE  will 
require  a  smooth  cutover.  Three  cutover  alternatives  are: 

a.  Alternative  1:  Physically 
install  I-S/A  AMPE  and  establish  circuits  to  two  higher 
level  elements.  Dual  connect  "back  side"  AMPE  circuits  on 
both  AMPE  and  I-S/A  AMPE.  Operationally  test  I-S/A  AMPE. 
Cutover  from  AMPE  to  I-S/A  AMPE  and  close  down  AMPE. 

b.  Alternative  2:  Physically 

install  and  home  I-S/A  AMPE  as  above.  Connect  AMPE  to  back 
side  of  IS/A  AMPE.  Individually  cutover  back  side  AMPE 
circuits.  Close  down  AMPE. 


is 
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c.  Alternative  3:  Rehome  back 
side  AMPE  users  to  nearby  nodes  (i.e.,  PSNs,  I-S/A  AMPE,  or 
AMPEs) .  Close  down  and  physically  remove  AMPE.  Install  I- 
S/A  AMPE  and  home  to  two  higher  level  elements.  Re-establish 
back  side  users  on  the  I-S/A  AMPE. 

Alternative  3  significantly  impacts  other  network  elements 
and  should  be  considered  only  when  physical  limitations 
demand  AMPE  removal  prior  to  I-S/A  AMPE  installation. 
Alternative  1  is  preferred  over  Alternative  2  because  it 
allows  I-S/A  AMPE  test  and  evaluation  in  a  near-operational 
environment  prior  to  final  cutover. 

2.  AMPE  Replacement  Strategy.  The 
transition  from  AMPEs  to  I-S/A  AMPEs  will  be  marked  by  the 
incremental  addition  of  I-S/A  AMPEs  to  the  network  beginning 
in  1982  primarily  based  on  the  remaining  useful  service  life 
of  existing  AMPEs.  Consequently,  the  replacement  of  some 
AMPEs  can  be  absorbed  by  I-S/A  AMIEs  that  were  fielded  for 
other  reasons  (i.e.,  to  replace  a  nearby  AMPE  or  to  satisfy 
new  requirements  for  I-S/A  AMPE  service) .  This  will  happen 
when  an  AMPE  located  close  to  an  operational  I-S/A  AMPE 
requires  replacement.  In  this  event,  AMPE  subscribers  could 
be  rehomed  to  the  nearby  I-S/A  AMPE  followed  by  cutover  and 
removal  of  the  AMPE. 


2-  Survivability/Availability.  To 
enhance  survivability  and  availability,  I-S/A  AMPEs  should 
be  dual  homed  to  two  higher  level  elements;  i.e.,  two  PSNs, 
two  I-S/A  AMPE (E) s ,  or  one  PSN  and  one  I-S/A  AMPE(E).  As 
discussed  in  Section  III  it  is  preferable  to  connect  the  I- 
S/A  AMPE  to  a  PSN  and  an  I-S/A  AMPE(E)  in  order  to  facilitate 
optimum  traffic  routing  and  enhanced  survivability. 

4.  Overseas  Implications.  AMPE 
equipments  located  overseas  may  reach  the  end  of  their 
useful  service  life  and  require  replacement  prior  to  introduc¬ 
tion  of  I-S/A  AMPE(E)  service  overseas.  In  this  event, 
homing  of  replacement  I-S/A  AMPEs  presents  two  options.  The 
I-S/A  AMPEs  can  be  homed  to  PSNs  or  CONUS  I-S/A  AMPE(E)s; 
however,  the  use  of  intercontinental  trunks  for  this  purpose 
is  undesirable  from  both  cost  and  survivability  considera¬ 
tions.  Alternatively,  I-S/A  AMPEs  could  be  homed  to  a 
remaining  overseas  ASC  via  the  available  AUTODIN  I,  Mode  I 
interface.  This  would  provide  an  interim  solution  until 
eventual  ASC  replacement. 

5..  AMPE  Support  Requirements.  Based 
on  AMPE  service  life  projections  and  installation  schedules, 
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a  significant  number  of  AMPEs  will  not  require  replacement 
in  the  mid- term  time  frame  and,  therefore,  must  be  supported 
into  the  far-term. 


(d)  ASC  Replacement.  The  enhanced  I-S/A 
AMPE(E),  a  modular  expansion  of  the  I-S/A  AMPE,  will  contain 
AMPE  replacement  functions  and  the  residual  ASC  functions 
e.g.,  message  switching,  multiple  address  routing.  Because 
of  the  high  cost  associated  with  the  operation  and  maintenance 
of  ASCs,  a  high  priority  will  be  placed  on  phasing  out  the 
ASCs .  The  initial  installations  of  I-S/A  AMPE(E)s,  projected 
for  early  1985,  will  be  carefully  planned  so  that  each 
installation  is  accompanied  by  the  closure  of  an  ASC. 

Two  considerations  will  be  factored  into  the  transition 
strategy  cutover  and  I-S/A  AMPE  site  selection.  In  the 
near-term  the  number  of  ASCs  in  CONUS  and  Overseas  will  be 
reduced.  With  the  implementation  of  I-S/A  AMPEs  and  additional 
PSNs,  the  ASCs  will  be  required  only  to  perform  the  message 
processing  function  for  store  and  forward  traffic.  It  is 
these  functions  which  the  I-S/A  AMPE(E)  will  be  designed  to 
perform.  Hence  elimination  of  ASCs  becomes  possible. 

1^.  Overseas  ASC  Trunking.  The 
primary  issue  in  overseas  trunking  is  maintaining  diversity 
in  the  event  of  failures.  The  preferred  connection  for 
trunking  is  via  the  PSNs,  but  additional  trunk  connections, 
e.g.,  0/S  I-S/A  AMPE(E)  to  CONUS  PSN  may  be  desirable  until 
sufficient  PSNs  are  fielded  overseas.  Prior  to  fielding  the 
I-S/A  AMPE  (E)  the  ASCs  will  in  some  cases  maintain  their 
own  trunking  subnet.  When  the  I-S/A  AMPE(E)  is  fielded, 
connection  between  ASCs  would  be  maintained  only  if  PSN 
connections  are  found  to  be  insufficient. 

2.  Rehoming  Directly  Connected  ASC 
Subscribers.  AUTODIN  I  subscriber  terminals  that  are  directly 
connected  to  an  ASC  must  be  rehomed.  Rehoming  of  terminals 
will  be  evaluated  on  a  case-by-case  basis.  AUTODIN  I  terminals 
can  be  rehomed  alternatively  to  an  I-S/A  AMPE,  or,  if  a  Mode 
I  terminal,  to  an  I-S/A  AMPE(E)  via  PSN  transfer.  Consideration 
for  each  affected  terminal  should  be  given  to  minimizing 
transmission  cost  and  to  the  final  mid-term  IAS  configuration. 

A  less  attractive  rehoming  option  is  to  rehome  to  an  AMPE. 

This  would  result  in  another  rehoming,  however,  when  that 
AMPE  is  phased  out.  This  is  inconsistent  with  planning  for 
a  smooth  transition. 


3.  ASC-PSN  Connections.  CONUS  ASCs 
are  connected  to  the  PSFT  for  two  purposes:  (1)  to  receive 
CONUS  trunking;  and  (2)  to  service  message  switching  requests 
from  remote  CONUS  subscribers.  Once  the  overseas  trunking 
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and  direct  subscriber  connection  problems  are  resolved,  the 
ASC  to  PSN  connection  will  only  be  used  for  message  switching 
service  requests.  The  PSNs  will  then  route  these  requests 
to  an  I-S/A  AMPE(E) ,  thereby  resulting  in  ASC  deactivation. 

4.  Cutover.  The  actual  installation 
of  an  I-S/A  AMPE(E)  is  identical  in  cutover  procedures  to 
the  installation  of  an  I-S/A  AMPE  with  one  exception.  That 
occurs  when  the  I-S/A  AMPE(E)  is  being  installed  in  a  location 
that  has  an  I-S/A  AMPE.  Those  modules  necessary  to  upgrade 
the  system  to  its  enhanced  version  should  be  loaded/configured 
without  disrupting  the  operational  system.  This  is  in 
keeping  with  continuity  of  service  and  user  transparency. 

5.  I-S/A  AMPE (E)  Site  Selection. 

Cutover  transition  considerations  that  should  be  applied  in 
selecting  sites  to  receive  the  ASC  replacements  are  discussed 
in  the  following  subparagraphs. 

a.  Local  Service.  I-S/A  AMPE(E)s 
will  be  deployed  as  AMPE  replacements  and/or  I-S/A  AMPE 
upgrades  and  will  reside  in  the  access  area.  They  will  be 
dual  connected  to  the  PSN  backbone  using  the  Mode  VI  Host 
interface.  I-S/A  AMPE(E)s  should  be  sited  to  minimize 
transmission  costs  by  taking  advantage  of  the  local  service 
implications  of  the  access  node  and  the  direct  homing  potential 
for  nearby  AMPEs  and  I-S/A  AMPEs.  Consideration  should  also 

be  given  to  former  ASC  sites  since  these  sites  may  possess 
needed  facilities  and  support  assets  that  could  reduce 
installation  cost. 

b.  Survivability.  Since  enhanced 
survivability  is  an  IAS  goal,  extra  consideration  should  be 
accorded  to  facilities  with  unique  survivability  provisions 
(e.g.,  hardening,  uninterruptable  power  supply). 

c.  Expandability.  The  primary 

purpose  for  initial  I-S/A  AMPE(E)  installations  is  to  facilitate 
ASC  phaseout.  Consequently,  the  primary  emphasis  during 
planning  stages  will  be  to  identify  those  I-S/A  AMPE(E) 
sites  that  will  permit  ASC  closings.  Requirements  for  I-S/A 
AMPE(E)  service  can  be  satisfied  by  upgrading  I-S/A  AMPE 
sites . 

(e)  New  Services.  As  currently  projected, 
requirements  for  new  network  services  such  as  mailbox  and 
teleconferencing  will  be  satisfied  through  modular  expansion 
of  the  I-S/A  AMPE(E).  The  modular  implementation  of  these 
services  offers  a  great  deal  of  flexibility  in  configuring 
I-S/A  AMPE(E)s  to  provide  these  services.  As  an  extreme, 


these  modules  could  be  configured  on  a  network  element  other 
than  an  I-S/A  AMPE(E)  (e.g.,  to  provide  backup  capability). 
Requirements  for  these  modules  will  be  evaluated  on  a  case- 
by-case  basis. 

(2)  Expansion  of  Packet  Switch  Node  (PSN) 

Backbone.  The  mid-term  IAS  will  mark  the  emergence  of  a 
worldwide  data  backbone.  PSNs  will  be  deployed  in  both 
CONUS  and  overseas  to  augment  the  near-term  eleven  node 
network.  As  the  data  backbone  evolves,  transition  objec¬ 
tives  and  issues  take  on  the  following  significance. 

(a)  PSN  Expansion  -  Sequence  of  Events. 

It  is  undesirable  to  execute  a  transition  step  that  will  be 
reversed  by  subsequent  transition  steps.  In  this  regard, 
each  step  of  the  transition  should  reflect  as  closely  as 
possible  the  final  mid-term  configuration.  In  this  context, 
requirements  for  PSNs  should  be  identified  during  planning 
stages  through  consideration  of  the  deployment  of  other  mid¬ 
term  network  elements,  specifically,  the  I-S/A  AMPE,  I-S/A 
AHPE(E)  and  CFT.  The  installation  of  PSNs  should  be  closely 
coordinated  with  the  schedules  for  the  other  elements  so 
that  PSNs  are  fielded  first.  This  will  facilitate  a  smooth 
transition  by  eliminating  needless  iterative  rehoming  of 
subscriber  equipment  and  access  nodes.  Rehoming  is  unavoid¬ 
able  in  an  evolving  network,  but  it  can  be  kept  to  a  minimum 
through  careful  transition  planning. 

(b)  Overseas  PSN  Implications.  As  enhanced 
survivability  is  a  system  objective,  consideration  should  be 
given  to  deploying  smaller,  more  mobile  PSNs  overseas. 
Implementation  of  the  PSN  Terminal  Access  Control  functions 

in  the  I-S/A  AMPEs  should  facilitate  a  smaller  PSN  configuration. 

(3)  Common  Family  of  Terminals.  The  mid-term 
IAS  will  be  required  to  support  a  mix  of  subscriber  terminals 
that  fall  into  one  of  the  following  categories:  (1)  AUTODIN 
I  Terminals;  (2)  AUTODIN  II  Terminals;  (3)  AUTODIN  II  Host; 
and  (4)  Common  Family  of  AUTODIN  Terminals.  As  the  IAS 
evolves,  the  distinction  between  these  different  categories 
of  terminals  will  disappear  as  the  Common  Family  of  Terminals 
will  satisfy  subscriber  requirements.  Beginning  in  1984, 

the  common  family  of  terminals  will  be  used  to  fulfill  needs 
for  new  or  replacement  subscriber  equipment.  All  categories 
of  equipments  are  expected  to  exist  through  the  mid-term. 
Depending  on  the  service  needs  of  the  subscriber,  terminals 
will  be  terminated  on  AMPEs ,  I-S/A  AMPE,  I-S/A  AMPE(E)s,  or 
PSNs.  Table  10  shows  the  termination  alternatives  available 
to  a  subscriber.  Also,  with  the  I-S/A  AMPE(E)  located  in 


TABLE  10 


MID-TERM  IAS  TERMINATIONS 


Terminating  Device 

Network 

Component 

AMPE 

PSN 

I-S/A  AMPE 

I-S/A  AMPE(E) 

T 

E 

R 

H 

I 

N 

A 

L 

Ves 

* 

Yes 

Yes 

Yes 

AUTODIN  II 

No 

Yes 

Yes 

Yes 

AUTODIN  II 
(Host) 

No 

Yes 

TEE 

TBE 

BUI 

No 

Yes 

Yes 

Yes 

Mode  I  only,  (terminated  to  PSN  but  homed  to 

I-S/A  AMPE(E) } 

TBE--T0  Be  Evaluated 


114 


the  access  area,  dual  homing  may  be  employed  for  those  pro¬ 
grammable  terminals  capable  of  selecting  the  best  path 
relative  to  the  service  desired.  Such  terminals  would  be 
dual  homed  to  a  PSN  and  an  I-S/A  AMPE(E). 

(4)  Integration  Of  Security  Components.  The 
mid-term  IAS  will  feature  the  introduction  of  an  end-to-end 
encryption  (E  )  capability.  This  capability  will  be  based 
on  the  use  of  BLACKER  hardware  and  software  components. 
Transition  considerations  for  these  elements  are  provided  in 
a  separate  classified  appendix  (Appendix  4). 

(5)  Milestones  and  Schedule.  The  overall 
strategy  for  transitioning  from  the  near-term  to  the  mid¬ 
term  IAS  can  be  postulated  in  terms  of  sequence  of  events, 
target  dates,  and  the  interdependencies  of  events.  The 
transition  considerations  discussed  in  the  preceding  para¬ 
graphs  have  been  factored  into  a  recommended  transition  plan 
as  shown  in  Table  11  and  Figure  25.  Table  11  lists  the 
required  activities  and  their  associated  target  dates  in 
chronological  order.  Figure  25  presents  these  activities  as 
a  milestone  chart.  The  transition  strategy  is  a  feasible 
approach  to  achieving  the  mid-term  IAS  in  a  deliberate  and 
continuous  manner.  It  also  provides  the  framework  for  more 
detailed  network  element  transition  plans. 

4.  Far-Term  IAS. 


a.  Elements.  The  far- term  IAS  is  defined  as  a 
third  generation  (Post  1988)  integrated  data  communications 
system  to  be  developed  in  conjunction  with  the  other  third 
generation  (DCS  III)  subsystems.  These  interrelated  DCS 
subsystems  include  Automatic  Voice  Network  (AUTOVON) ,  Auto¬ 
matic  Secure  Voice  Communications  (AUTOSEVOCOM) ,  the  IAS, 

The  Defense  Satellite  Communications  System  (DSCS) ,  and  the 
Automated  Technical  Control  (ATEC)  System.  The  far-term 
architecture  elements  should  proceed  initially  from  the  near 
to  mid-term  system  architecture  and  should  include  the 
AUTODIN  II  PSNs ,  the  I-S/A  AMPEs  and  the  common  family  of 
AMPE  remote  and  AUTODIN  terminals.  The  terrestial  switched 
and  broadcast  satellite  architecture  alternatives  for  the 
far- term  IAS,  along  with  the  identification  of  major  network 
elements,  are  described  in  Section  IV  of  the  IASA  Report 
(Part  1). 

b.  Transition  Strategy.  The  far-term  DCS,  to 
include  the  IAS,  should  evolve  from  the  near  and  mid-term 
architecture  approaches.  The  functional  allocation  scheme, 


TABLE  11 


MID-TERM  IAS  TRANSITION  PLAN 


Activity 


CY  Target  Date 


Start  Development  of  I-S/A  AMPE  Family  of  Nodes  1979 
Start  Development  of  Common  Family  of 

Terminals  1979 

Start  Mid-Term  Topology  Design  &  Related  Studies  1979 


Start  Development  of  New  Services  and  Functions 
Detailed  Definition  of  Functions  for  I-S/A  AMPE 
HOL  Decision  (DoD) 


1980 

1980 

1981 


Begin  Development  of  HOL  Software  for  I-S/A  AMPE  1981 

Mid-Term  IAS  System  Implementation  Plan  Developmentl981 

Definition  of  Services  and  Functions  for  I-S/A 

AMPE  1982 

Begin  Fielding  I-S/A  AMPE  (Phase  I)  1982 

Begin  PSN  Expansion  (0/S  and  CONUS  as  required)  1984 

Begin  Fielding  Common  Family  of  Terminals  1984 

Begin  AMPE  Phaseout  (Phase  II)  1984 

Begin  Fielding  I-S/A  AMPE  (E)  (Phase  II)  1985 

Begin  Phaseout  of  Remaining  ASCs  1985 

Begin  Fielding  End-to-End  Encryption  Equipment  1986 

Complete  Phaseout  of  0/S  ASCs  1987 


‘A 


4 

% 

jK 


s.  Complete  Phaseout  of  CONUS  ASCs 

t.  Mid-Term  IAS  Architecture  Achieved 
U.  Complete  AMPE  Phaseout 


1988 


1988 

1990 
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illustrated  in  Figure  16,  should  continue  into  the  far- term 
IAS.  In  addition,  the  projected  Service/Agency  AMPE  replace¬ 
ment  requirements,  identified  in  Appendix  2,  Table  13,  will 
influence  the  extent  of  I-S/A  AMPE  implementation  into  the 
far-term  IAS.  End-to-end  encryption  should  be  ar  integral 
part  of  the  far- term  IAS. 

(1)  The  DCS,  which  provides  common-user  switched 
services  and  long-haul  transmission  backbone  lor  defense 
communication  needs,  has  started  to  convert  from  an  analog 

to  a  digital  based  capability.  Evolutionary  planning  of 
near  through  far- term  DCS  common  user  record  and  data  conrauiu  a- 
tions  is  proceeding  under  the  IASA  project  and  will  evolve 
into  the  far-term  DCS.  Transmission  facilities  are  being 
tailored  to  support  an  extensive  digital,  second-generation 
secure  voice  capability,  while  later  stages  of  the  fully, 
integrated  digital  DCS  architecture  should  support  a  much 
broader  World  Wide  Digital  System  Architecture  (WWDSA) . 

Defining  this  integrated  digital  system  is  an  ongoing  DCA 
task,  results  to  be  promulgated  in  future  DCS  plans. 

(2)  The  feasible  union  of  AUTOSEVOCOM  and 
AUTOVON  services  will  be  evident  as  AUTOVON  becomes  the 
primary  carrier  for  secure  voice  services.  The  Secure  Voice 
Improvement  Program  (SVIP)  should  introduce  a  secure  voice 
terminal  to  replace  the  AUTOVON  four-wire  stations.  AUTOVON 
itself  will  change  in  an  evolutionary  manner  exploiting 
developments  in  commercial  telephony,  and  it  may  later 
become  the  vehicle  for  economically  providing  interswitch 
trunks  and  access  lines  for  the  AUTODIN  network. 

(3)  The  IAS  components  to  include  PSNs ,  I-S/A 
AMPEs  and  subscriber  terminals  will  make  maximum  use  of  the 
throughput  capability  and  efficiencies  of  digital  data 
trunks  and  access  lines  coupled  with  exploitation  of  packet 
switching  technology. 

(4)  In  transmission,  the  use  of  Pulse  Code 
Modulation/ Time  Division  Multiplexing  (PCM/TDM)  should 
exploit  the  advantages  of  end-to-end  digital  operation 
without  the  use  of  wireline  modems,  although  this  will  be  a 
very  gradual  process.  In  line  with  the  probable  far-term 
satellite  broadcast  architecture  for  the  IAS,  exploitation 
of  access  advantages  in  satellite  operation  with  small 
satellite  terminals  near  customer  premises  should  exist  in 
the  mid  to  far- term  (post  1988)  time  frame. 
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(5)  The  integration  of  transmission  and  circuit 
switching  accompanied  by  the  on-going  removal  of  channel 
banks,  associated  patching,  testing,  and  distribution  frames 
should  offer  increased  potential  for  reducing  annual  recur¬ 
ring  costs  in  the  far-term  DCS.  For  instance,  the  use  of 
commercial  circuit  switches  as  automatic  patching  and  wiring 
facilities  should  make  it  possible  to  carry  special  purpose 
networks  as  "dedicated  time  slots"  carrying  special  travel¬ 
ing  class  marks. 

(6)  Figure  26  illustrates  a  far-term  (post 
1988)  transition  approach.  As  shown,  through  evolution  the 
various  subsystems  should  become  an  integrated  voice/data 
system  based  on  digital  technology  and  end-to-end  encryption. 

5.  Integrated  AUTODIN  System  (IAS)  RDT&E.  Significant 
DCA  and  Service /Agency  Research,  Development ,  Test  and 
Evaluation  (RDT&E)  will  be  required  to  meet  the  user  demands 
for  improved  service  at  reduced  costs. 

a.  The  major  RDT&E  requirements  are: 

(1)  Prepare  IAS  interface  standards,  protocols, 
and  operating  procedures. 

(2)  Develop,  test,  and  evaluate  the  common 
family  of  AUTODIN  terminals. 

(3)  Develop  the  Higher  Order  Language  (HOL)  and 
an  overall  Software  Engineering  System. 

(4)  Complete  the  Network  Security  Analysis. 

(5)  Develop,  test,  and  evaluate  the  basic  and 
enhanced  I- S/A  AMPE. 

(6)  Establish  and  evaluate  "pilot"  services 
including  gateway  functions. 

(7)  Develop  long  range  IAS  Architecture  in  the 
context  of  the  future  integrated  DCS  design  and  concepts. 

b.  Reference  is  made  to  Table  12  for  a  summary  of 
IAS  RDT&E  funds  for  the  period  FY  1977-1985. 
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SECTION  V 


CONCLUSIONS  AND  RECOMMENDATIONS 


A.  Conclusions . 

1.  The  previous  sections  to  this  IAS A  project  report 
have  presented  a  picture  of  the  AUTODIN  system  from  the 
perspective  of  mid-term,  1984-1988,  architectural  alter¬ 
natives.  This  report  identified  alternative  architectures 
for  the  mid-term  and  described  the  process  and  rationale  for 
selecting  the  preferred  (Alternative  II)  architecture.  Based 
upon  user  requirements  and  the  need  to  provide  more  efficient 
common-user  AUTODIN  service,  a  transition  strategy  has  been 
provided  from  today's  AUTODIN  capabilities  to  the  circa  1990 
Integrated  AUTODIN  System. 

2.  The  overall  objective  of  the  IASA  project  is  to 
design  and  engineer  a  system  based  upon  AUTODIN  I  and 
AUTODIN  II,  which  is  complete  and  integrated  from  end  to 
end.  The  IASA  design  is  by  necessity  evolutionary  in 
development,  with  the  key  ingredient  being  responsiveness  to 
user  needs.  In  meeting  this  objective,  the  IASA  project  has 
logically  been  divided  into  three  parts.  The  December  1977 
IASA  Report  (Part  1)  provided  AUTODIN  implementation  alterna¬ 
tives  and  recommendations  through  1983.  This  report  (Part 

2)  provides  architectural  alternatives  for  the  period  1984 
through  1988.  In  October  1979  an  IASA  (Part  3)  report  will 
be  provided  to  include  standards  and  functional  specifica¬ 
tions  for  a  common  family  of  terminals . 

3.  The  conclusions  presented  in  the  IASA  Report  (Part 
1)  remain  valid.  The  AUTODIN  terminal- to- terminal  analysis 
presented  in  this  Part  2  report  has  resulted  in  the  following 
conclusions : 


a.  The  near-term  (1979-1983)  IAS  architecture 
should  provide  an  AUTODIN  system  that  is  responsive  to  the 
needs  of  both  narrative/record  and  data  users.  On  the  other 
hand,  the  1983  IAS  does  not  represent  an  acceptable  conclusion 
to  the  integration  process. 

b.  There  is  need  for  continued  evolution  to  a  mid¬ 
term  Integrated  AUTODIN  System  Architecture. 

c.  The  roles  and  relationships  of  components  of  the 
IAS  are  identified  to  include  AUTODIN  I,  AUTODIN  II,  AMPEs, 
I-S/A  AMPEs,  and  the  common  family  of  terminals. 
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d.  The  1983  IAS  should  consist  of  eleven  to  fifteen 
AUTODIN  I  switching  centers  (four  to  eight  in  CONUS  and  seven 
overseas) ,  and  eleven  AUTODIN  II  packet  switching  nodes  (eight 
in  CONUS  and  three  overseas) . 

e.  The  1983  IAS  represents  an  increase  in  standard¬ 
ization  cf  AMPE  and  terminal  operation/ configuration  through 
introduction  of  Inter-Service/Agency  AMPEs. 

f.  Enroute  to  developing  functional  specifications 
for  a  common  family  of  terminals  a  joint  Service/ Agency 
teletypewriter  replacement  program  has  been  established. 

g.  Interoperability  to  tactical  and  NATO  forces 
will  be  enhanced  through  their  direct  standard  connections 
to  AUTODIN  elements. 

h.  The  1983  IAS  represents  improvement  in  cost 
effectiveness  as  a  result  of  the  closure  of  one  or  more  ASCs 
and  consolidation  of  ASC  and  PSN  sites. 

i.  The  IAS  security  subsystem  will  satisfy  three 
basic  requirements:  (1)  provide  a  transparent,  secure 
switching /transmission  system  for  subscribers  using  the  IAS 
as  a  basic  communications  backbone;  (2)  provide  subscribers 
secure  special  network  services;  and  (3)  provide  reliable 
security  services  with  minimum  life  cycle  costs.  Additional 
conclusions  in  the  area  of  security  are  provided  in  the 
classified  Appendix  4. 

j .  The  DoD  Automated  Message  Handling  Systems 
(AMHS)  plan  states  the  IASA  project  is  the  means  whereby 
telecommunications  AMHS  objectives  are  achieved. 

k.  Eighty  telecommunications  functions  have  been 
identified  and  allocated  to  the  elements  of  the  mid-term  IAS 
Architecture  consisting  of  terminals  and  nodal  facilities. 

l.  A  DoD  standard  DD  Form  173  Joint  Messageform  has 
been  developed  and  approved  by  the  Military  Communications - 
Electronics  Board  (MCEB)  with  mandatory  implementation  by  1 
January  1980. 

m.  A  staffing  standard  for  manual  and  semi-automated 
cations  centers  has  been  developed  and  forwarded 
for  approval  and  implementation. 

n.  For  the  mid-term  three  alternative  architecture 
configurations  have  been  evaluated  and  compared  based  upon 


telecommuni 
to  ASD/C JI 


,e  criteria  of  operational  effectiveness,  flexibility, 
irvivability/availability/supportability ,  transition  and 
st.  As  a  result  of  this  analysis,  the  preferred  architecture 
ror  the  mid-term  IAS  should  be  based  upon  a  distributed 
architecture  (Alternative  II) ,  whereby  services  are  provided 
from  a  common  access  area  element.  The  major  elements  of 
the  architecture  are  the  AUTODIN  II  PSNs,  the  Inter-Service/ 
Agency  (I-S/A)  AMPEs  and  subscriber  terminals.  This  archi¬ 
tectural  structure  moves  switching  functions  closer  to  the 
user  by  use  of  the  enhanced  I-S/A  AMPE,  and  in  consonance 
with  recent  planning  efforts  for  DCS  architectures,  it  will 
reduce  the  dependency  on  the  more  vulnerable  backbone  switches 
and  should  enhance  overall  survivability. 

o.  The  mid-term  transition  strategy  is  driven  by 

the  following  architectual  objectives:  (1)  preserve  continuity 
of  existing  network  services;  (2)  provide  for  needed  new 
services;  (3)  enhance  system  survivability;  (4)  enhance 
tactical  and  allied  forces  interoperability;  and  (5)  replace 
obsolete  equipment  with  new  or  augmented  standard  network 
elements . 

p.  The  Inter-Service/Agency  (I-S/A)  AMPE  will  be 
used  to  satisfy  all  requirements  for  new  or  replacement 
AMPEs.  An  enhanced  version  of  this  network  element,  the  I- 
S/A  AMPE(E),  in  addition  to  providing  AMPE  functions  and 
services,  will  assume  the  functional  role  of  the  near-term 
ASC  and  will  provide  network  services  currently  outside  the 
scope  of  the  near-term  system. 

q.  The  preferred  architecture: 

(1)  is  consistent  with  the  mid-term  IAS  objec¬ 
tives  and  is  capable  of  providing  all  of  the  identified 
services  and  functions; 

(2)  offers  significant  opportunity  for  reduc¬ 
tion  in  O&M  cost  through  standardization  of  Service/Agency 
message  processing  and  communications  hardware,  software  and 
operation  procedures. 

(3)  provides  the  improved  access  reliability 
for  users  through  multiple  interconnection  of  network  access 
nodes ; 

(4)  permits  the  introduction  of  significant  new 
telecommunication  services  and  features; 

(5)  permits  improved  speed  of  service  and 
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overall  increased  network  responsiveness  to  user  needs; 

(6)  provides  the  flexibility  needed  to  allow 
the  mid-term  AUTODIN  system  to  accommodate  many  unique  user 
requirements  without  penalty  to  other  users; 

(7)  can  be  implemented  in  a  smooth  evolutionary 
process  from  the  near-term  1983  architecture  and  provides  the 
framework  for  continued  evolutionary  development  of  the  IAS 
through  1988  and  beyond. 

B.  Recommendations. 


1.  The  recommendations  presented  in  the  IASA  Report 
(Part  1)  remain  valid  and  steps  have  been  taken  to  implement 
these^actions .  For  example,  based  on  our  recommendation, 

ASD/u  I  directed  the  DCA  to  establish  an  I-S/A  AMPE  program. 
This  program  has  since  been  defined  with  appropriate  milestones 
to  implement  the  first  I-S/A  AMPE  element  in  1982. 

2.  As  a  result  of  efforts  to  identify,  correlate,  and 
project  the  Services/Agencies  AUTODIN  mid-term  (1984-1988) 
requirements,  the  following  recommendations  are  that: 

a.  Alternative  II  architecture  be  approved  for 
implementation. 

b.  Services/Agencies  be  active  participants  in  de¬ 
fining  telecommunications  requirements  and  developing  func¬ 
tional  specifications  for  the  common  family  of  terminals,  to 
include  the  I-S/A  AMPE. 

c.  Services /Agencies  identify  requirements  for 
AUTODIN  II  service  overseas. 

d.  The  IASA  Project  Office  monitor  the  MCEB  develop¬ 
ment  of  a  joint  Plain  Language  Address  Directory  and  a 
message  delivery  system  for  AUTODIN  terminals  as  opposed  to 
initiating  parallel  development  efforts. 

e  Services/Agencies  maintain  close  coordination 
with  DCA  on  the  physical  consolidation  of  Special  Intelligence 
and  General  Service  telecommunications  centers.  This  contact 
should  insure  requirements  and  lessons  learned  are  factored 
into  the  I-S/A  AMPE  program. 

f.  Analysis  be  performed  to  determine  personnel 
overhead  requirements  to  manage  the  IAS  implementation. 

This  analysis  should  include  software  development /maintenance , 
logistics  support,  training  and  program  management. 
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APPENDIX  1 


ACP 

ADP 

ALPS 

AF  AMPE 

AMHS 

AMME 

AMPE 

ARPA 

ARPANET 

ASC 

ASCII 

ASD/C3I 

(ASD/CCCI) 

ATEC 

ATP 

AUTOSEVOCOM 

AUTODIN 


ACRONYMS 

-  Allied  Communications  Publication 

-  Automatic  Data  Processing 

-  AUTODIN  Limited  Privacy  Service 

-  Air  Force  AMPE 

-  Automated  Message  Handling  System 

-  Automated  Multi -Media  Exchange 

-  Automated  Message  Processing  Exchange 

-  Advanced  Research  Projects  Agency 

-  Advanced  Research  Projects  Agency  Network 

-  AUTODIN  Switching  Center 

-  American  Standard  Code  for  Information 
Inter- Change 

-  Assistant  Secretary  of  Defense /Command 
Control  Communications  and  Intelligence 

-  Automated  Technical  Control 

-  Automated  Telecommunications  Program 

-  Automatic  Secure  Voice  Communications 

-  Automatic  Digital  Network 


BSL 

BCR 

BDT 


-  Binary  Segment  Leader 

-  BLACK- CRYPTO- REP 

-  Bulk  Data  Transfer 


CC 


-  Crypto  Concentrator 
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ecu 


Common  Control  Unit 


CFT 

CINCPAC 

CINCEUR 

COMSEC 

CONUS 

CSF 

DARPA 

DCA 

DCEC 

DEMO 

DLA 

DODIIS 

DSCS 

DSSCS 

DSTE 

DTACCS 


EUCOM 

F 

FACC 

FKV 


-  Common  Family  of  Terminals 

-  Commander-in-Chief  Pacific 

-  Commander-in-Chief  Europe 

-  Communications  Security 

-  Continental  United  States 

-  Central  Service  Facility 

-  Defense  Advanced  Research  Projects  Agency 

-  Defense  Communications  AGency 

-  Defense  Communications  Engineering  Center 

-  Demonstration 

-  Defense  Logistics  Agency 

-  Department  of  Defense  Information 
Intelligence  System 

-  Defense  Satellite  Communications  System 

-  Defense  Special  Security  Communications 
System 

-  Digital  Subscriber  Terminal  Equipment 

-  Director  Telecommunications  and  Command 
and  Control  Communications  System 

-  End-to-End  Encryption 

-  European  Command 

-  Ford  Aerospace  and  Communications 
Corporation 

-  Frank furt-Koenigstuhl-Vaihingen 
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FYP 


-  Five  Year  Program 


GAO 

- 

Government  Accounting  Office 

GENSER 

- 

General  Service 

GFE 

- 

Government  Furnished  Equipment 

HAC 

- 

House  Appropriations  Committee 

HOL 

- 

High  Order  Language 

I/A 

- 

Interactive 

IAS 

- 

Integrated  AUTODIN  System 

IASA 

- 

Integrated  AUTODIN  System  Architecture 

IMP 

- 

Interface  Message  Processor 

IOC 

- 

Initial  Operational  Capability 

IRT 

- 

Interim  Remote  Terminal 

I-S/A  AMPE 

- 

Inter-Service/Agency  Automated  Message 
Processing  Exchange 

I-S/A  AMPE(E) 

- 

Inter- Service/ Agency  AMPE  (Enhanced) 

JANAP 

- 

Joint  Army  Navy  Air  Force  Publication 

JCS 

_ 

Joint  Chiefs  of  Staff 

Kbits 

kbs  or  Kbps 
KD 


-  Kilobits 

-  Kilobits  per  second 

-  Key  Distribution 

-  Key  Distribution  Center 


KDC 


KG 

KGU 

KSOS 

L 

LCM 

LDMX 

LSI 

M 

MCCU 
MCEB 
MILDEPS 
MIL- STD 
MLS 
MOP 
MRTT 
MTBF 
MTCC 
MULT ICS 
N 

NATO 

NAVCOMPARS 

NCC 

NFE 

NTCS 

NIDS 


-  Key  Generator 

-  Key  Generating  Unit 

-  Kernelized  Security  Operating  System 

-  Line  Control  Module 

-  Local  Digital  Message  Exchange 

-  Large  Scale  Integration 

-  Multiple  Channel  Control  Unit 

-  Military  Communications-Electronics  Board 

-  Military  Departments 

-  Military  Standard 

-  Multi-level  Security 

-  Memorandum  of  Policy 

-  Modular  Record  Traffic  Terminal 

-  Mean  Time  Between  Failure 

-  Modular  Tactical  Communication  Center 

-  Multiplexer  Information  and  Computing  Service 

-  North  Atlantic  Treaty  Organization 

-  Naval  Communications  Processing  and  Routing 
System 

-  Network  Control  Center 

-  Network  Front  End 

-  Nato  Inteerated  Communications  System 

-  NMCC  Information  and  Display  System 
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NMCC 

NMIC-SS 

0 

OCR 

OJCS 

O/S 

OSD 

P 

PAC 

PACOM 

PCM 

PLA-RI 

PLAD 

PLI 

PSN 

a 

Q/R 

R 

R&D 

RDT&E 

RI 

R/Y 

S 

SACDIN 


-  National  Military  Command  Center 

-  National  Military  Intelligence  Center 
Support  Subsystem 

-  Optical  Character  Reader 

-  Office  of  Joint  Chiefs  of  Staff 

-  Overseas 

-  Office  of  the  Secretary  of  Defense 

-  Pacific 

-  Pacific  Command 

-  Pulse  Code  Modulation 

-  Plain  Language  Addressing  -  Routing  Indicator 

-  Plain  Language  Address  Directory 

-  Private  Line  Interface 

-  Packet  Switch  Node 

-  Query  Response 

-  Research  and  Developement 

-  Research  Development  Test  and  Evaluation 

-  Routing  Indicator 

-  Code  used  in  TCC  Operations  for  GENSER/ 

DSSCS  Operations 

-  Strategic  Air  Command  Automatic  Digital 
Network 
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sccu 

SCI 

SCM 

SDC 

SNFE 

SIP 

SRI 

SRT 

SST 

SV 

SVIP 

T 

TAC 

TARE 

TCC 

TCP 

TDM 

THP 

TRI-TAC 

U 

UCLA 

V 

VAN 

VM 

VHP 


-  Single  Channel  Control  Unit 

-  Sensitive  Compartmented  Information 

-  Switch  Control  Module 

-  Software  Development  Corporation 

-  Secure  Network  Front  End 

-  Segment  Interface  Protocol 

-  Stanford  Research  Institute 

-  Standard  Remote  Terminal 

-  Single  Subscriber  Terminal 

-  Secure  Voice 

-  Secure  Voice  Improvement  Program 

-  Terminal  Access  Control 

-  Teletypewriter  Automated  Relay  Equipment 

-  Telecommunications  Centers 

-  Transmission  Control  Program 

-  Time  Division  Multiplexing 

-  Terminal  to  Host  Protocol 

-  Joint  Tactical  Communications  Office 

-  University  of  California  at  Los  Angeles 

-  Value  Added  Network 

-  Virtual  Machine 

-  Virtual  Message  Protocol 
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AMPE  AND  INTER- SERVICE/ AGENCY  AMPE 
REQUIREMENTS  (1982-1990) 


APPENDIX  2 


AMPE  AND  INTER- SERVICE /AGENCY  AHPE 
REQUIREMENTS  (1982-1990) 


A.  Purpose .  The  purpose  of  this  appendix  is  to  analyze  the 
projected  requirements  for  the  AMPE  and  Inter-Service/Agency 
Automated  Message  Processing  Exchange  (I-S/A  AMPE)  as  an 
input  to  the  mid-term  IAS  architecture.  This  appendix  also 
includes  development  of  AMPE  replacement  strategy.  The 
analysis  and  the  projections  presented  herein  are  for  planning 
purposes  only.  Detailed  site  by  site  implementation  plans 
remain  to  be  developed. 

B.  Assumptions .  The  assumptions  that  form  the  basis  for 
the  following  Analysis  are : 

1.  A  standard  AMPE  for  Inter-Service/Agency  use  will  be 
available  in  1982. 

2.  The  projected  AMPE  population  by  1983  should  be  109 
broken  down  as  follows : 


Service/Agenc^ 

Navy 

Army 

Air  Force 
NS  A 
DLA 


Number  of  AMPEs 


Total  109 

The  analysis  assumes  that  Army  and  Navy  projected  AMPE 
installations  through  1982  should  proceed  as  planned.  Air 
Force  projected  AMPE  requirements  through  1981  should  be 
deployed  using  their  AF  AMPE,  with  projected  requirements 
for  1982  and  beyond  satisfied  by  I-S/A  AMPEs. 

3.  Existing  DLA  AMPEs  (fielded  in  the  early  1970s) 
should  be  replaced  between  1982  and  1984  using  the  I-S/A 
AMPEs. 


4.  The  service  life  of  all  current  AMPEs  is  estimated 
at  eight  to  ten  years. 

5.  AMPE  requirements  identified  for  the  period  1978- 
1982  indicate  a  growth  in  AMPE  population  of  8%  to  9Z  per 
year. 


6.  A  four  percent  rate  of  growth  is  projected  for  I-S/A 
AMPEs  beginning  in  1982;  one  fourth  of  that  rate  of  growth 
should  be  absorbed  through  AMPE  consolidations  on  I-S/A 
AMPEs  and  the  remaining  three  fourths  should  be  satisfied  by 
new  I-S/A  AMPE  installations. 

7.  All  NSA  STREAMLINER  AMPEs  should  be  replaced  between 
1985  and  1987  based  on  their  fielding  dates  (1977-1978)  and 
assumed  service  life. 

8.  LDMX-I  systems  (single  70/45  processor)  should  be 
replaced  in  the  1985-1987  time  frame  based  on  service  life. 

9.  AMPEs  within  50  miles  of  each  other  should  be  replaced 
by  a  single  I-S/A  AMPE  or  by  two  I-S/A  AMPEs  if  more  than 
three  AMPEs  are  involved.  Otherwise,  replacement  of  AMPEs 

by  I-S/A  AMPEs  should  be  on  a  one-for-one  basis. 

10.  AMPE  testbed  facilities  should  remain  in  place  as 
long  as  any  AMPEs  of  the  corresponding  Service  or  Agency  are 
still  in  the  field. 

C.  Analysis . 

1.  A  total  of  109  AMPEs  are  currently  projected  to  be 
in  place  by  the  end  of  1982,  thirty-one  of  which  are  NSA 
STREAMLINER  systems.  An  analysis  of  the  AMPEs  was  performed 
on  a  case  by  case  basis  from  which  replacement  dates  and 
consolidation  strategies  were  developed.  The  results  of  the 
analysis  are  presented  in  Table  13.  The  78  projected  AMPEs 
belonging  to  Army,  Navy,  Air  Force,  and  DLA  are  listed  by 
geographical  location.  Also  shown  is  the  time  frame  in 
which  each  AMPE  should  be  replaced  along  with  potential 
consolidation. 

2.  Additional  notes  related  to  Table  13  are: 

.  STREAMLINER  locations  are  CONFIDENTIAL  and  are 
therefore  not  listed. 

.  Army  AMPEs  that  are  not  already  in  place  have  the 
projected  installation  date  listed  along  with  the 
location  name. 

Navy  AMPEs  are  identified  by  system  type  (LDMX 
or  NAVCOMPARS)  and  generation  (I  or  II).  Those 
that  are  not  yet  in  place  have  the  projected 
installation  date  listed. 


Eleven  of  the  Air  Force  AMPE  locations  are 
labled  "NEW".  These  represent  1982  and  delayed 
1981  requirements  (Assumption  2)  that  should  be 
satisfied  by  I-S/A  AMPE  rather  than  the  current 
AF  AMPE  program.  Seven  of  the  requirements  are 
met  via  consolidation  on  I-S/A  AMPEs  installed  to 
replace  one  Navy  and  three  DLA  locations. 

3.  The  population  of  AMPEs  and  I-S/A  AMPEs  through  the 
mid-term  and  into  the  far- term  IAS  can  be  derived  from  Table 
13.  These  figures  are  shown  numerically  in  Table  14  and 
graphically  in  Figure  27.  Although  NSA  AMPE  locations  are 
not  listed  in  Table  13,  an  analysis  of  these  locations  in¬ 
dicated  that  eight  sites  could  potentially  be  consolidated 
with  other  Inter- Service/Agency  AMPEs  with  the  remaining 
twenty-three  sites  replaced  by  I-S/A  AMPEs.  These  have  been 
included  in  the  net  increase  of  36  replacement  I-S/A  AMPEs 
shown  for  the  1985-1987  time  frame  in  Table  14. 

D.  Conclusions .  Without  the  I-S/A  AMPE  program  and  consoli¬ 
dation  of  AMPE  sites,  the  number  of  AMPEs  should  exceed  150 
by  1990  based  on  the  projected  rate  of  growth.  The  I-S/A 
AMPE  program,  with  106  I-S/A  AMPEs  in  1990,  represents  a 
potential  347„  savings  in  the  number  of  elements. 
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APPENDIX  3 
COST  ANALYSIS 


A.  Introduction . 

1.  Purpose .  The  purpose  of  this  appendix  is  to  describe 
the  major  aspects  and  results  of  a  comparative  cost  analysis 
performed  in  support  of  the  mid-term  IAS  architecture 
definition  effort.  The  analysis  focused  on  two  objectives: 
comparative  evaluation  of  candidate  mid-term  architectures, 
and  comparison  between  the  preferred  mid-term  alternative 
and  the  baseline  architecture  projected  to  the  mid-term. 

2.  Background .  A  few  preliminary  observations  are  in 
order.  First ,  the  analysis  of  alternatives  is  comparative. 
Therefore,  costs  common  to  all  of  the  alternatives  have  been 
excluded  in  order  to  simplify  the  analysis.  Secondly,  the 
analysis  seeks  to  select  a  least-cost  alternative  without 
resorting  to  an  exhaustive  life-cycle  cost  effort  which  would 
require  detailed  information  on  implementation  strategy. 
Therefore,  the  analysis  is  limited  to  the  level  of  detail 
necessary  to  the  identification  of  trends  and  projections 
which  provide  an  adequate  basis  for  relative  cost  comparison 
and  ranking  among  alternatives . 

3.  Approach.  The  basic  approach  to  the  cost  analysis 
consists  of  the  following  steps: 

a.  Identification  and  analysis  of  major  cost 
elements.  From  a  complete  list  of  elements,  only  those 
found  to  be  dependent  upon  network  architecture  have  been 
retained.  These  are  transmission  cost,  nodal  element 
acquisition  cost,  and  nodal  element  operation  and 
maintenance  cost. 

b.  Identification  of  architecture  dependent  cost 
factors  within  each  cost  element.  Again,  costs  which  are 
common  to  all  three  architectures  have  been  discarded. 

c.  Development  of  cost  estimating  relationships 
or  costing  methods  for  each  cost  factor.  In  cases  where 

a  mathematical  expression  is  not  applicable  or  is  difficult 
to  obtain,  a  costing  method  has  been  developed  which 
produces  the  cost  value  for  given  parameter  values. 
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d.  Evaluation  of  architecture  dependent  cost  factors. 
The  cost  factors  are  evaluated  using  nominal  parameter  values. 

e.  Sensitivity  analysis.  Parameters  and  assumptions 
are  varied  and  the  impact  on  cost  is  assessed.  Those  which 
drive  the  total  cost  are  identified. 

f.  Accumulation  of  cost  factors  and  ranking  of  alter¬ 
natives.  The  cost  factors  within  each  major  cost  element  are 
evaluated  and  aggregated  into  a  total  element  cost.  The 
total  cost,  together  with  sensitivity  and  other  considerations, 
is  used  to  rank  the  alternatives. 

g.  Overall  cost  ranking  of  alternatives.  The  results 
associated  with  each  major  cost  element  are  combined  into  a 
final  ranking.  The  relative  weights  of  the  cost  elements  are 
factored  into  this  evaluation  process. 

4.  Assumptions .  Additional  general  assumptions  and 
ground  rules  that  support  the  cost  analysis  are  presented 
below. 


a.  The  number  of  subscriber  terminals  and  host  com¬ 
puters  in  the  system  is  independent  of  the  architectural 
alternative.  This  cost  component  has  been  excluded  from  the 
comparative  analysis. 

b.  For  simplicity,  the  cost  impact  of  certain  archi¬ 
tectural  issues  was  not  factored  into  the  analysis.  Prime 
examples  are  security  and  system  management  and  control. 

These  issues  were,  however,  addressed  under  various  technical 
criteria. 


c.  Within  each  major  cost  element  the  analysis 
focused  on  those  cost  factors  which  contribute  the  most  to 
total  cost.  Items  subordinate  to  these  primary  factors  will, 
in  general,  follow  the  primary  factors  and  only  increase  the 
magnitude  of  any  comparative  cost  difference. 

d.  The  cost  calculations  are  expressed  in  current 
1978  dollars.  The  uncertainty  associated  with  the  mid-term 
implementation  strategy,  as  well  as  the  requirement  for 
comparative  results,  made  the  added  complexity  of  price  level 
and  discount  factors  unjustifiable. 

e.  The  cost  analysis  presented  in  this  appendix 
assumes  a  typical  1988  network  configuration  for  each  alter¬ 
native  architecture  for  the  purpose  of  computing  nominal 
costs.  Based  on  these  mid-term  configurations,  a  projected 
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network  element  inventory  was  developed.  This  inventory  took 
into  account  both  geographic  and  survivability  considerations 
in  order  to  determine  the  probable  minimum  number  of  each  type 
of  element  required  for  each  alternative.  Typical  CONUS  and 
overseas  configurations  for  the  1988  alternatives,  as  well  as 
the  expected  1983  baseline,  are  presented  in  Table  15. 

B.  Comparison  Among  Alternative  Mid-Term  Architectures. 

1.  Transmission  Cost.  Following  the  approach  outlined 
above,  comparative  transmission  costs  for  the  three  alter¬ 
natives  were  computed.  This  involved  sizing  and  costing 
various  links  in  the  network,  using  the  backbone  and  access 
area  topologies  specified  in  the  traffic  model. 

a.  Assumption  Guidelines.  The  following  assumptions 
and  guidelines  were  used  in  analyzing  transmission  costs: 

(1)  Link  traffic  estimates  were  used  in  sizing 
communication  lines.  The  analysis  was  limited  to  narrative/ 
record  (N/R)  and  bulk  data  transfer  (BDT)  traffic.  Estimates 
of  interactive  and  query/response  (Q/R)  requirements  show 
these  to  represent  a  relatively  minor  contribution  to  total 
AUTODIN  traffic  (less  than  570)  .  Narrative/record  estimates 
were  furnished  by  the  traffic  analysis  computer  model,  which 
takes  into  account  the  various  subscriber  types,  their 
distribution,  connectivity  and  service  requirements.  Esti¬ 
mated  BDTs  were  computed  in  a  similar  manner.  This  traffic 
consists  of  terminal-to-computer  and  computer-to-computer 
transfers,  and  requires  no  services  from  a  CSF  or  I-S/A 
AMPE(E) . 


(2)  Consistent  with  the  comparative  character 
of  the  analysis,  those  links  carrying  the  same  traffic  in 
all  three  alternatives  were  neglected.  For  the  remaining 
links,  however,  the  total  traffic  (architecture  dependent 
and  independent  components)  are  used  for  sizing.  This  last 
category  includes  PSN-to-PSN  and  PSN-to-CSF  links  in  the 
backbone,  as  well  as  I-S/A  AMPE(E) -to-PSN  and  I-S/A  AMPE- 
to-PSN  links  in  the  access  area. 

(3)  Cost  calculations  were  based  on  estimates 
of  1988  average  busy  hour  traffic,  assuming  1988  link 
configurations . 

(4)  Transmission  facility  lease  costs  were 
calculated  based  on  available  common  carrier  bulk  tariffs 
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for  both  voice-grade  and  wideband  circuits.  Rates  (in  current 
dollars)  include  mileage  dependent  and  service  (fixed)  charges 
as  follows: 

(a)  56  Kbps  trunks  in  the  backbone  ($6.72/ 

mi/mo,  $920/mo) . 

(b)  300-9600  baud  lines  in  the  access  area 
($0. 56/mi/mo,  $86. 60/mo).  Source:  Defense  Commercial 
Communications  Office.  NOTE:  All  lines  are  full-duplex,  with 
capacity  determined  by  the  largest  of  the  two  unidirectional 
flows . 

(5)  For  simplicity,  modem  and  multiplexer  costs 
were  assumed  to  be  architecture  independent,  and  were  excluded 
from  the  calculations.  In  addition,  no  attempt  was  made  to 
optimize  circuit  selection  by  mixing  available  offerings 

(the  impact  would  be  to  lower  costs  farily  evenly) . 

(6)  A  nominal  link  utilization  factor  of  50%  was 
used  in  this  study,  to  account  for  overhead,  traffic  growth, 
and  delay  performance  requirements.  The  effect  of  varying 
this  value  is  discussed  later,  as  a  sensitivity  issue. 

(7)  All  elements  were  assumed  to  be  single-homed 
for  simplicity.  The  impact  of  dual  homing  on  transmission 
cost  is  addressed  later. 

(8)  The  transmission  cost  study  is  restricted  to 
CONUS  configurations.  However,  it  is  likely  that  overseas 
alternatives  will  either  be  very  similar  (i.e.,  architecture 
independent) ,  or  implemented  according  to  the  corresponding 
CONUS  strategy,  in  which  case  the  same  comparative  results 
(ranking)  should  hold. 

b.  Summary.  There  is  no  significant  variation  in 
transmission  cost  among  the  three  alternatives.  As  would  be 
expected,  Architecture  I  shows  a  slightly  greater  cost  than 
the  other  two  alternatives.  This  stems  from  the  fact  that 
all  traffic  requiring  services  must  access  a  backbone -homed 
CSF.  On  the  other  hand,  Alternatives  II  and  III  offer  some 
or  all  of  these  services  closer  to  the  subscriber,  in  access 
area  elements.  In  any  event,  the  variation  in  total  cost  is 
no  greater  than  about  6%.  If  costs  common  to  all  three 
architectures  were  included,  this  variation  would  be  further 
reduced . 

The  number  of  service  elements  and  the  connection  strategy 
for  I-S/A  AMPEs  were  chosen  as  architectural  variables,  while 


holding  other  parameters  constant.  In  order  to  assess  the 
impact  of  several  of  the  assumptions  discussed  earlier,  the 
sensitivity  of  the  results  to  changes  in  these  parameters  was 
investigated.  The  parameters  were  varied  over  a  reasonable 
range  of  values  so  as  to  identify  trends  in  the  behavior  of 
the  cost  results.  The  findings  are  summarized  in  Table  16. 

As  indicated  in  the  table,  variations  in  most  parameters  tend 
to  affect  all  three  architectures  fairly  equally,  thus 
producing  no  significant  effect  on  the  comparative  evaluation. 
Although  the  cost  comparison  applies  to  1988  configurations, 
with  sin-flar  topologies  and  comparable  1984-1988  transition 
plans,  the  evaluation  results  can  be  expected  to  hold 
throughout  the  mid-term. 

In  view  of  these  considerations,  transmission  cost  does 
not  represent  a  driving  factor  in  the  selection  of  a  preferred 
architecture.  The  cost  variations  obtained  are  of  the  same 
order  of  magnitude  as  the  error  associated  with  many  of  the 
underlying  assumptions.  Thus,  no  alternative  can  be  singled 
out  as  best  and  the  three  architectures  have  been  ranked 
equally. 

2.  Nodal  Element  Acquisition  Cost.  The  comparative 
evaluation  of  potential  acquisition  costs  for  the  alternative 
mid-term  architectures  relied  on  the  following  assumptions 
and  guidelines : 

a.  Assumptions/Guidelines. 

(1)  The  estimation  of  acquisition  costs  focused 
on  nodal  element  hardware  costs,  as  well  as  basic  operating 
system  software  costs.  A  sof tware-f irst  development  approach 
was  assumed  for  applications  software  (which  supports  AUTODIN 
functions  and  services),  using  transportable  software  modules 
designed  to  run  on  all  of  the  alternative  hardware  configu¬ 
rations.  Since  all  three  architectures  must  provide  the  same 
functions  and  services,  applications  software  development 
costs  were  regarded  as  architecture  independent  and  excluded 
from  the  analysis. 


(2)  Security  functions  (e.g.,  access  control,  key 
distribution)  and  multilevel  security  are  to  be  provided 
through  separate  subsystems.  As  mentioned  earlier,  these 
issues  were  addressed  under  technical  rather  than  cost  criteria 
(see  Appendix  4).  In  any  event,  it  is  expected  that  the 
implementation  cost  will  be  fairly  uniform  for  the  three 
alternatives . 


(3)  The  militarization  of  nodal  element  hardware 
(I-S/A  AMPE  and  I-S/A  AMPE(E))  is  to  be  accomplished  under 
the  I-S/A  AMPE  program,  and  thus  has  been  excluded  from  the 
analysis.  The  militarization  of  I-S/A  AMPE(E)s  should  entail 
no  additional  cost. 

(4)  Although  some  nodal  elements  may  be  leased, 
the  cost  estimating  approach  made  use  of  one-time  acquisition 
costs  for  convenience.  In  situations  requiring  an  annual 
cost  figure,  the  one-time  cost  was  distributed  uniformly  over 
a  ten  year  economic  lifetime. 

(5)  In  the  specification  of  nodal  hardware  con¬ 
figurations  maximum  commonality  and  modularity  were  assumed. 
Furthermore,  the  nodal  elements  were  based  on  a  multi¬ 
processor  architecture. 

(6)  Cost  estimates  for  network  elements  were 
based  on  commercial  hardware  suitable  for  a  fixed  plant 
environment,  and  do  not  include  the  cost  of  spare  parts, 
documentation  or  other  support  costs. 

(7)  Acquisition  cost  figures  are  expressed  in 
1978  dollars. 

b.  Approach.  In  accordance  with  the  preceding 
ground  rules,  acquisition  costs  of  all  major  network  elements 
were  estimated  using  the  approach  described  below. 

(1)  Representative  hardware  configurations  were 
defined  for  the  nodal  elements  of  each  alternative  architecture 
(PSNs  were  assumed  architecture  independent,  and  excluded  from 
the  analysis) .  These  configurations  are  required  to  support 
communications  processing,  service  processing,  and  control 
processing.  Each  element  was  defined  in  terms  of  a  standard 
set  of  hardware  components  (e.g.,  processor,  memory, 
peripherals)  selected  from  typical  state-of-the-art  communi¬ 
cations  processing  systems. 

(2)  The  network  elements  were  sized,  using  the 
set  of  standard  components,  based  on  the  following  inputs: 
functional  capabilities  required  to  support  services  allocated 
to  the  nodal  elements;  projected  nodal  throughput  require¬ 
ments  provided  by  the  automated  traffic  model;  and  the  typical 
subscriber  circuit  and  network  trunk  inventories  (classified 
according  to  transmission  speed  and  link  protocol),  derived 
from  available  AUTODIN  projections.  These  inputs  were  used 
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to  determine  the  requirements  for  processing  power,  memory 
and  peripherals,  as  well  as  the  operating  system  to  manage 
them.  Network  element  costs  were  then  computed,  based  on 
hardware  component  cost  estimates  collected  through  vendor 
surveys  and  available  literature.  Finally,  the  total  nodal 
element  acquisition  cost  was  compiled  for  each  alternative 
mid-term  architecture,  using  the  typical  network  configu¬ 
rations  of  Table  15. 

(3)  The  Tymshare  Engine,  a  commercial  processor, 
was  selected  as  the  basic  building  block  in  defining  nodal 
element  configurations.  This  unit,  used  as  a  nodal  processor 
in  a  value-added  network  (Tymnet) ,  was  chosen  for  several 
reasons:  (1)  the  Engine  was  specifically  designed  for 

communications  processing;  (2)  it  is  suitable  for  a  multi¬ 
processor  nodal  architecture,  and  is  fairly  modular  in 
structure;  (3)  it  evolved  from  the  Interdata  7/32,  a  well- 
known  minicomputer.  Furthermore,  it  is  similar  to  the  AF 
AMPE,  which  is  also  based  on  the  7/32;  it  is  software  com¬ 
patible  with  the  7/32,  and  is  supported  by  the  same 
peripherals;  and  it  is  a  more  powerful  enhanced  version  of 
the  7/32;  (4)  the  Engine  is  representative  of  state-of-the- 
art  technology. 

The  Engine  should  be  viewed  as  a  "strawman"  hardware 
implementation  useful  in  a  comparative  analysis,  rather  than 
a  nodal  architecture  recommendation.  The  nodal  element  hard¬ 
ware  sizing  procedure  is  illustrated  in  Figure  28,  for  the 
case  of  an  I-S/A  AMPE  (common  to  all  three  architectures) . 

The  configuration  includes  two  Engine  processors,  one  for 
communications  processing  and  one  for  service  processing  (with 
control  functions  present  in  both) ,  as  well  as  the  necessary 
peripherals,  storage  devices  and  I/O  parts. 

To  avoid  redundant  effort,  the  specification  of  hardware 
configurations  was  performed  on  network  elements  in  order  of 
increasing  capability.  In  this  way,  the  structure  of  one 
element  could  build  on  the  hardware  configuration  of  a  less 
powerful  element  (which  supports  a  subset  of  the  functions 
and  services  of  the  first  one)  by  adding  extra  components  and 
capabilities.  The  results  of  the  nodal  element  acquisition 
cost  analysis  are  shown  in  Figure  29.  The  diagram  also  depicts 
the  order  in  which  these  elements  were  configured,  starting 
from  a  set  of  standard  components.  The  cost  of  an  I-S/A  AMPE 
was  calculated  in  spite  of  its  architecture  independence, 
since  it  represents  an  intermediate  step  in  the  definition  of 
an  I-S/A  AMPE(E).  The  "large"  and  "small"  versions  of  the 
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ELEMENT  ACQUISITION  COST  RESULTS 


I-S/A  AMPE(E)s  result  from  different  assumed  I-S/A  AMPE(E) 
populations.  The  smaller,  more  pervasive  type  is  assumed  in 
the  typical  configurations  presented  in  Table  15  used 
throughout  this  study. 

c.  Summary.  Based  on  typical  1988  network  configu¬ 
rations  and  derived  element  acquisition  costs,  the  overall 
acquisition  cost  for  each  alternative  architecture  was 
computed.  The  results  are  summarized  in  Table  17.  Elements 
irrelevant  to  a  comparative  analysis  have  been  excluded.  It 
is  evident  from  the  results  that  total  nodal  element  acqui¬ 
sition  cost  does  not  vary  greatly  among  the  alternatives. 

In  addition,  when  the  expected  economic  life  of  the  elements 
is  considered  (about  10  years),  the  potential  difference  in 
annual  lease  cost  is  less  significant. 

Several  observations  should  be  made  in  the  area  of  sensi¬ 
tivity.  First,  the  simplifying  assumption  of  uniform  soft¬ 
ware  development  costs  does  not  reflect  the  additional 
complexity  and  cost  of  developing  and  implementing  software 
for  more  than  one  service  element.  Taking  this  into  account 
would  penalize  Alternative  III  while  making  Alternative  II 
more  attractive.  The  likely  effect  would  be  to  reverse  the 
acquisition  cost  ranking  presented  in  Table  17  showing  a 
slight  preference  for  Architecture  II.  The  variation  in 
cost,  however,  should  still  be  relatively  insignificant. 

Finally,  the  assumption  that  would  appear  to  have  the 
greatest  impact  on  the  acquisition  cost  ranking  is  the  number 
of  network  elements  (i.e.,  the  assumed  1988  configurations). 
However,  because  of  performance  and  survivability  constraints, 
no  appreciable  variation  from  the  nominal  values  is  anticipated. 
Furthermore,  the  cost  advantage  of  a  decrease  in  the  population 
of  a  service  element  is  partially  offset  by  an  increase  in 
unit  cost  for  the  remaining  elements,  arising  from  additional 
throughput  and  service  processing  requirements. 

3.  Operation  and  Maintenance  Cost.  Of  the  major  compo¬ 
nents  of  operation  and  maintenance  (0  &  M)  cost  -  personnel, 
spares  and  back-up  equipment,  facilities  support  (0  &  M  instal¬ 
lations)  ,  and  utilities  -  personnel  costs  represent  the  largest 
contribution  to  total  cost.  In  view  of  this,  the  analysis  of 
operation  and  maintenance  cost  focuses  on  personnel  require¬ 
ments,  and  addresses  the  remaining  factors  in  terms  of  the 
sensitivity  of  the  results. 

a.  Assumptions/Guidelines.  The  assumptions  used  to 
calculate  personnel  costs  for  the  candidate  architectures 
are  described  below: 
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TABLE  17 


PROJECTED  NETWORK  ELEMENT  ACQUISITION  COST 


ARCHITECTURE 

ALTERNATIVE 

NODAL  ELEMENT 
INVENTORY 

ESTIMATED  COST 

PER  ELEMENT 

ESTIMATED  SYSTEM 
ACQUISITION  COST 
(IB78S) 

1 

1 CSF 

7B  l-S/A  AMPE 

“  (DELETED) 

l-S/A  AMPE 

(DELETED) 

II 

S3  l-S/A  AMPE 

IS  l-S/A  AMPE(E) 

l-S/A  AMPE  (DELETE! 
l-S/A  AMPE(E) 

)  (DELETED) 

III 

6  CSF 

SB  l-S/A  AMPE 

12  l-S/A  AMPE(E) 

*  (DELETE 

l-S/A  AMPE 

l-S/A  AMPE(E) 

D)  (DELETED) 

NOTES 

1.  EACH  ELEMENT  HAS  SEEN  DEFINEO  IN  TERMS  OF  HARDWARE  COMPONENTS  SELECTEO 
FROM  TYPICAL  STATE-OF-THE-ART  COMMUNICATIONS  PROCESSING  SYSTEMS. 

2.  COST  ESTIMATES  REPRESENT  PROJECTED  ACQUISITION  COSTS  FOR  NETWORK  ELEMENTS 
BASED  ON  COMMERCIAL  HAROWARE  SUITABLE  TO  A  FIXED  PLANT  ENVIRONMENT.  ANO 

DO  NOT  INCLUOE  THE  COST  OF  SPARE  PARTS,  DOCUMENTATION,  OR  OTHER  SUPPORT  COSTS. 

1  COST  ESTIMATES  00  NOT  INCLUOE  AMORTIZATION  OF  HARDWARE  OR  SOFTWARE  DEVEL¬ 
OPMENT  COSTS. 

A  ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  1SSS  NETWORK  CONFIGURATIONS. 
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(1)  Projected  manning  requirements  and  annual  pay 
rates  (by  personnel  category)  used  throughout  the  operation 
and  maintenance  cost  analysis  are  shown  in  Table  18.  The  table 
includes  present  ASC  and  AMPE  levels  for  reference,  as  well  as 
estimated  levels  for  nodal  elements  used  in  the  alternative 
mid-term  architectures  and  the  projected  baseline. 

(2)  The  estimates  for  ASC  and  AMPE  personnel 
were  obtained  from  available  data  on  existing  operations.  In 
particular,  personnel  requirements  for  the  ASCs  are  based  on 
a  Joint  Service  Human  Resources  Staffing  Standard  and  Guide 
for  ASCs,  dated  1  Nov  1978.  They  include  some  indirect 
personnel,  primarily  in  the  areas  of  facilities  0  &  M  and 
hardware  maintenance.  Some  categories  have  been  aggregated 
for  simplicity  (e.g.,  Hardware  Maintenance  includes  Computer, 
DSTE,  Teletypewriter  and  Modem  Maintenance) .  The  standard 
personnel  categories  used  are  indicated  in  Table  18.  Esti¬ 
mates  for  AMPE  personnel  requirements  were  based  on  proposed 
manning  levels  identified  in  Service  provided  AMPE  plans.  In 
order  to  ensure  a  meaningful  comparison  among  network  elements , 
the  personnel  categories  were  assigned  comparable  categories 
developed  for  the  ASC.  (These  categories  are  estimated  by 
extrapolation  from  available  data  collected  in  the  AMPE 
studies  and  provided  in  the  IASA  Report  (Part  1),  Appendix  2.) 
Finally,  the  requirements  for  each  category  were  adjusted  to 
account  for  variations  in  AMPE  types  and  sizes  (the  values  in 
Table  18  represent  overall  averages) . 

(3)  The  manning  estimates  for  new  IAS  elements 
were  obtained  using  the  available  ASC  and  AMPE  information 

as  a  baseline.  These  figures  were  then  projected  and  adjusted 
for  each  element  in  question,  with  consideration  given  to 
element  throughput  requirements,  anticipated  processing 
capabilities,  communication  line  and  trunk  terminating  require¬ 
ments  and  advances  in  technology. 

(4)  The  following  additional  assumptions  and 
guidelines  were  used  in  preparing  Table  18. 

(a)  The  Hardware  Maintenance  category  has 
been  included  for  comparative  purposes,  to  illustrate  the 
potential  savings  offered  by  the  new  IAS  elements  (mainte¬ 
nance  is  provided  by  contractors  in  all  CONUS  and  many 
overseas  elements). 

(b)  The  manning  levels  shown  in  the  table 
include  more  than  the  operations  personnel  but  are  restricted 
to  personnel  whose  primary  responsibility  centers  around  the 
proper  functioning  of  the  network  element. 


See  Table  notes  next  page 


TABLE  18 


Notes 

1.  "ASC  1988  Levels"  represent  reduced  O&M  personnel  require¬ 
ments  that  will  result  from  introduction  of  new  technology 
replacement  subsystem  during  1978-1988  period  (e.g., 
second  generation  crypto  equipments). 

2.  "AMPE  1988  Levels  (Original)"  represents  O&M  personnel 
requirements  for  AMPEs  which  have  been  deployed  during 
the  1970s  and  remain  in  operation  throughout  the  mid-term. 
The  only  personnel  reduction  relative  to  present  levels 
arises  in  the  area  of  crypto  maintenance,  as  a  result  of 
the  introduction  of  second  generation  equipment. 

3.  "AMPE  1988  Levels  (Replacement)"  represent  O&M  personnel 
requirements  for  AMPEs  which  are  planned  for  deployment 
during  the  near-term  to  replace  current  AMPEs.  These 
replacement  AMPEs  show  a  reduction  in  hardware  maintenance 
requirements  as  a  result  of  a  certain  degree  of  standardi¬ 
zation  and  technological  innovation  in  many  of  the  sub¬ 
systems  . 

4.  Manning  levels  include  only  those  personnel  whose  primary 
responsibility  centers  around  the  proper  functioning  of  the 
network  elements. 

j.  The  Hardware  Maintenance  category  has  been  included  for 
comparative  purposes  (in  many  instances  this  service  is 
provided  by  contractor) . 

6.  The  Facilities  Operations  &  Maintenance  category  includes 
power  production,  air  conditioning  maintenance,  etc. 

7.  The  personnel  requirements  represent  site  totals,  assuming 
four  shifts. 

8.  Manning  levels  are  for  ASCs  and  AMPE  1978  levels  are  assumed 
to  be  averaged  over  the  total  population  of  an  element 
(both  CONUS  and  Overseas) . 

2.  Yearly  costs  are  weighted  averages  of  the  ASC  personnel 

breakdown  under  each  major  category.  The  appropriate  rates 
are  taken  from  the  DCA  Cost  and  Planning  Factors  Manual 
(DCAC  600-60-1),  and  include  base  pay  plus 

costs  for  retirement,  training,  recruiting  and  other  support 
costs.  Costs  are  in  1978  dollars. 
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(c)  The  personnel  requirements  represent  site 
totals,  assuming  four  shifts. 

(d)  Manning  levels  are  assumed  to  be  averaged 
over  the  total  population  of  an  element  (both  CONUS  and  Over¬ 
seas)  . 


(e)  Yearly  costs  were  weighted  averages  of 
the  ASC  personnel  breakdown  under  each  major  category. 

b.  Summary.  As  a  result  of  the  above,  system  person¬ 
nel  requirements  and  total  annual  costs  were  computed  for  the 
alternative  architectures  (Table  19) .  As  indicated  in  this 
table,  Alternative  II,  when  compared  with  Alternatives  I  and 
III,  represents  an  additional  savings  of  about  200  personnel, 
which  would  result  in  an  additional  estimated  annual  0  &  M 
cost  reduction  of  about  $4  million.  Although  the  remaining 
components  of  operation  and  maintenance  costs  were  not  calcu¬ 
lated  in  this  analysis,  it  can  be  expected  that  consideration 
of  additional  0  &  M  factors  would  increase  the  cost  advantage 
of  Architecture  II  over  the  other  alternatives .  Thus ,  the 
various  types  of  nodal  elements  require  similar  installations, 
and  hence  the  total  cost  of  these  additional  factors  tends  to 
be  primarily  a  function  of  the  number  of  elements  favoring 
the  alternative  with  the  smallest  element  inventory.  No 
significant  variation  in  the  assumed  1988  element  inventories 
is  anticipated. 

In  view  of  these  considerations.  Alternative  II  is 
preferred.  This  conclusion  should  hold  throughout  the 
mid-term,  assuming  comparable  implementation  plans  for  the 
three  candidates . 

4.  Cost  Comparison  Summary.  In  order  to  obtain  a 
meaningful  overall  ranking  of  the  alternatives  based  on  their 
cost  performance,  the  relative  weight  of  each  cost  category 
should  be  considered.  Although  the  comparative  cost  analysis 
specifically  avoided  calculating  costs  common  to  all  alterna¬ 
tives,  sufficient  information  is  available  to  permit  first 
order  estimates  of  the  total  system  costs. 

a.  Transmission  Costs  -  the  comparative  analysis 
yielded  an  annual  cost  of  about  $6  million  ($500K/mo)  for 
CONUS.  Inclusion  of  the  architecture  independent  portion 
of  access  area  costs,  and  extension  of  the  analysis  to  over¬ 
seas,  produces  a  figure  of  approximately  $20  million  per 
year. 
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TABLE  19 

PROJECTED  O&M  PERSONNEL  COST 


ARCHITECTURE 

ALTERNATIVE 

NODAL  ELEMENT 
INVENTORY 

PERSONNEL 

REQUIRED 

ESTIMATED 

ANNUAL  06M 
PERSONNEL  COST 
(1978  $K  PER  YEAR) 

■ 

11  PSN 

693 

13,442 

I 

6  CSF 

372 

7,020 

78  I-S/A  AMPE 

+  5,850 

+  114,192 

6,915 

134,654 

11  PSN 

693 

13,442 

II 

15  I-S/A  AMPE  (E) 

1,275 

24,795 

63  I-S/A  AMPE 

+  4,725 

+  92,232 

6,693 

130,469 

III 

11  PSN 

693 

13,442 

6  CSF 

288 

5,718 

12  I-S/A  AMPE  (E) 

972 

18,924 

66  I-S/A  AMPE 

+  4,950 

+  96,624 

6,903 

134,708 

NOTES : 

1.  NODAL  ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  1988  NETWORK 
CONFIGURATIONS . 

2.  PERSONNEL  REQUIREMENTS  REPRESENT  SITE  TOTALS,  ASSUMING  FOUR 
SHIFTS . 

3.  PERSONNEL  RATES  ARE  BASED  ON  AVERAGE  YEARLY  COSTS. 
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b.  Nodal  Element  Acquisition  Costs  -  the  compara¬ 
tive  analysis  showed  an  annual  cost  of  approximately  . 
(DELETED)  The  addition  of  costs  common  to  the  three  alterna¬ 
tives  (such  as  software  development,  installation,  etc.)  is 
expected  to  double  this  figure.  Amortization  over  a  10  year 
economic  life  yields  an  estimated  annual  cost  of  (DELETED) 

c.  Operation  and  Maintenance  Costs  -  the  analysis 
of  personnel  costs  was  quite  comprehensive,  and  led  to  an 
annual  figure  of  about  $130  million.  Additional  OcM  costs 
for  utilities,  facilities  support,  and  spares,  suggest  a 
total  annual  cost  of  approximately  (DELETED) . 

C .  Comparison  of  Preferred  Mid-Term  Architecture  to  Projected 
Baseline 

1 .  The  Projected  Baseline. 

a.  Purpose.  The  purpose  of  this  section  is  to  gain 
insight  into  the  potential  advantage  of  implementing  tb** 
preferred  (Alternative  II) ,  mid-term  IAS  architecture  .  The 
comparative  cost  analysis  was  expanded  to  include  comparison 
of  the  preferred  architecture  with  the  1983  baseline  archi¬ 
tecture  projected  to  a  probable  1988  configuration  (presented 
in  Table  15) .  The  projected  baseline  architecture  would 
incorporate  only  those  changes  and  upgrades  required  to  main¬ 
tain  current  system  capabilities.  The  projected  baseline, 
when  compared  with  the  preferred  alternative  architecture, 
provides  an  indication  of  the  impact  that  will  result  if 
little  or  no  action  is  taken  toward  the  evolution  of  the 
AUTODIN  system.  In  addition,  this  comparison  emphasizes  the 
potential  cost  savings  of  the  preferred  architecture. 

b.  Assumptions/Guidelines.  The  projected  1983 
baseline  architecture  is  based  on  the  following  assumptions : 
(1)  ASCs  retained  in  operation  with  minimum  essential  hard¬ 
ware/software  subsystem  replacement;  and  (2)  AMPEs  retained 
in  all  current  locations  and  replaced  at  the  end  of  their 
useful  service  life  with  a  "standardized"  AMPE.  Based  on 
current  DoD  policy,  the  projected  baseline  architecture 
includes  provision  for  replacement  of  existing  AMPEs  with 
some  form  of  standardized  AMPE.  However,  because  these 
equipments  would  not  have  additional  capability  of  the 
I-S/A  AMPE  used  in  the  preferred  architecture,  it  is  un¬ 
realistic  to  assume  that  consolidation  could  be  achieved 
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in  the  projected  1983  baseline  architecture.  Therefore, 
the  number  of  AMPEs  projected  for  the  1988  configuration  was 
derived  from  current  and  planned  AMPE  requirements  (see 
Appendix  2) .  The  comparison  between  the  preferred  archi¬ 
tecture  and  the  projected  baseline  centers  on  major  cost 
elements,  but  extends  some  categories  to  include  common 
factors  (such  as  PSN  and  AMPE  costs) . 

2.  Transmission  Cost.  The  comparative  analysis  of 
transmission  cost  determined  relative  little  cost  sensitivity 
to  the  architectural  configuration  or  the  basic  underlying 
assumptions.  Furthermore,  the  projected  baseline  must 
provide  the  same  geographical  coverage,  and  meet  the  same 
performance  requirements  as  the  preferred  mid-term  archi¬ 
tecture.  Therefore,  no  significant  difference  in  link  con¬ 
figurations  is  anticipated.  The  preferred  architecture  may 
yield,  however,  some  cost  savings,  arising  from  the  more 
effective  use  of  traffic  concentration  and  nodal  processing. 

3.  Nodal  Element  Acquisition  Cost.  A  comparison  of 
projected  network  element  acquisition  cost  for  the  preferred 
architecture  versus  the  projected  baseline  was  performed, 
using  the  sane  basic  approach  and  assumptions  outlined 
above.  The  results  are  summarized  in  Table  20.  Only 
acquisitions  unique  to  each  architecture  have  been  included 
(original  AlIPEs  remaining  in  1988  and  PSNs  are  present  in 
both  alternatives) .  The  cost  of  replacement  AMPEs  ("stan¬ 
dardized")  was  estimated  at  80%  of  the  I-S/A  AMPE  cost.  As 
a  result,  total  estimated  acquisition  cost  of  the  preferred 
architecture  is  approximately  (DELETED)  greater  than  that 
of  the  projected  baseline.  However,  when  total  useful  service 
life  of  the  elements  is  considered,  the  cost  impact  is 
relatively  insignificant. 

4.  Operation  and  Maintenance  Cost.  The  comparison  of 
operation  and  maintenance  cost  for  the  preferred  architecture 
versus  the  projected  baseline  followed  the  same  procedure 
and  assumptions  used  to  select  the  preferred  alternative. 

The  analysis  focused,  again,  on  personnel  costs,  and  the 
comparative  results  are  summarized  in  Table  21.  As  evidenced 
by  this  table,  the  preferred  architecture  offers  a  potential 
net  savings  of  about  2000  personnel  with  a  resultant  net 
cost  savings  of  about  $39  million  per  year.  It  should  be 
noted  that  the  cost  analysis  takes  into  account  that  many 
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TABLE  20 


NODAL  ELEMENT  ACQUISITION  COST  COMPARISON 


REQUIRED 

ACQUISITIONS 

ESTIMATED  COST 
PER  ELEMENT 

(1B7I S) 
SYSTEM  COST 

PREFERRED 

MIDTERM 

IS  l-S/A  AMPE  (El 

(DELETED) 

(DELETED 

ARCHITECTURE 

S3  l-S/A  AMPE 

(DELETED) 

(DELETED 

(1SSSI 

PROJECTED 

BASELINE 

(1988) 

107  AMPE 
(REPLACEMENT) 

(DELETED 

(DELETED 

NOTES: 

1.  EACH  ELEMENT  HAS  BEEN  OEFINEO  IN  TERMS  OF  HARDWARE  COMPONENTS 
SELECTED  FROM  TYPICAL  STATE  OF  THE  ART  COMMUNICATIONS  PROCESSING 
SYSTEMS. 

2.  COST  ESTIMATES  REPRESENT  PROJECTED  ACQUISITION  COSTS  FOR  NETWORK 
ELEMENTS  BASED  ON  COMMERCIAL  HARDWARE  SUITABLE  TO  A  FIXED  PLANT 
ENVIRONMENT.  AND  00  NOT  INCLUDE  THE  COST  OF  SPARE  PARTS.  DOCUMENTS 
TION.  OR  OTHER  SUPPORT  COSTS. 

X  COST  ESTIMATES  DO  NOT  INCLUOE  AMORTIZATION  OF  HARDWARE  OR  SOFT 
WARE  DEVELOPMENT  COSTS. 

A  ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  19SS  NETWORK  CONFIGURA¬ 
TIONS.  (*See  Table  15) 

B.  SUNK  COSTS,  INCLUDING  PSNt,  TERMINALS.  ETC.,  HAVE  BEEN  EXCLUDED  FROM 
THE  COST  COMPARISON. 

S.  THE  AMPEt  SHOWN  IN  THE  PROJECTED  BASELINE  ELEMENT  INVENTORY 
ARE  STANOARDIZEO  AMPEi WHICH  REPLACE  CURRENT 
AMPEt  during  THE  mio-term.  (*See  Table  15) 

7.  THE  COST  OF  REPLACEMENT  AMPEt  WAS  ESTIMATED  AT  BOH  OF  THE 
l-S/A  AMPE  COST. 
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THE  PROJECTED  BASELINE  INCLUDES  CURRENT  AMPES  WHICH  WILL  BE  IN  SERVICE  THROUGH  1988 
AS  WELL  AS  STANDARDIZED  AMPES  WHICH  REPLACE  CURRENT  AMPES  DURING  THE  MID-TERM. 
PERSONNEL  OVERHEAD  COSTS  FOR  MANAGEMENT,  LOGISTICS  SUPPORT,  TRAINING  AND 
SOFTWARE  DEVELOPMENT/MAINTENANCE  ARE  NOT  INCLUDED  IN  ABOVE  FIGURES 


of  the  existing  and  planned  AMPE  sites  eliminated  through 
consolidation  will  revert  to  local  terminal/message  center 
operation.  As  a  result,  some  of  the  O&M  personnel  formerly 
required  at  the  AMPE  sites  will  be  retained  for  operation 
of  the  terminal/message  centers  (see  Table  18) .  The  magni¬ 
tude  of  the  potential  savings  indicated  by  this  analysis 
demonstrates  an  opportunity  for  reduction  of  total  AUTODIN 
system  operation  and  maintenance  cost  through  implementation 
of  the  preferred  (Alternative  II),  mid-term  IAS  architecture. 


